Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Fcp
Similar a Fcp (20)
Fcp
- 3. • たかはしなおと • TwitterID: tnaoto • クラウド基盤の開発
- 4. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
- 5. ICTの役割変化
- 8. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
- 9. アプリケーションアーキテクチャの変貌 戦略的投資は、試行錯誤、かつ、スピード勝負 • クラウド上でアプリケーションの運用 • メリット – ハードウェア不要 – 必要なリソースは必要な分だけ • デメリット – いままで運用してきたアプリケーションは要回収 – “秘伝のタレ”が使えない
- 10. ICTの役割変化 SoRとSoE • SoR:System of Record – 記録系業務システム • SoE:System of Engagement – SNSのようなヒトの関係性を表すシステム
- 11. クラウドによる変化 • 大規模分散処理 – Hadoop, CEPなど • オートスケールアウト/スケールイン – 動的負荷分散 • SDN(software Defined Network) – ネットワーク経路検索の動的プログラミング • 開発手法の変革 – アジャイルの普及/DevOps
- 12. アプリケーションアーキテクチャの変貌 • PaaS – クラウドネイティブアプリケーションの代表的な例 • 特徴 – 強い型決め – 開発者は、アプリケーションの開発にだけ注力 – OS、ハードは気にしなくて良い、 もしくは、気にすることが出来ない アプリケーションのアーキテクチャが変わる
- 13. THE TWELVE-FACTOR APP • http://twelve-factor-ja.herokuapp.com/ • I. コードベース (Codebase) バージョン管理されている1つのコードベースと複数 のデプロイ • II. 依存関係 (Dependencies) 依存関係を明示的に宣言し分離する • III. 設定 (Config) 設定を環境変数に格納する • IV. バックエンドサービス (Backing Services) バックエンドサービスをアタッチされたリソースとし て扱う • V. ビルド、リリース、実行 (Build, release, run) ビルド、リリース、実行の3つのステージを厳密に分 離する • VI. プロセス (Processes)アプリケーション を1つもしくは複数のステートレスなプロセスとして 実行する • VII. ポートバインディング (Port binding) ポートバインディングを通してサービスを公開する • VIII. 並行性 (Concurrency) プロセスモデルによってスケールアウトする • IX. 廃棄容易性 (Disposability) 高速な起動とグレースフルシャットダウンで堅牢性を 最大化する • X. 開発/本番一致 (Dev/prod parity) 開発、ステージング、本番環境をできるだけ一致させ た状態を保つ • XI. ログ (Logs) ログをイベントストリームとして扱う • XII. 管理プロセス (Admin processes) 管理タスクを1回限りのプロセスとして実行する
- 14. THE TWELVE-FACTOR APP • 日経コンピュータ 9/18 号 • 日経ITPro http://itpro.nikkeibp.co.jp/atcl/column /14/110900092/ • 12個のプラクティスを３つに分類 エンタープライズはどうするべきかを、 オリジナルの解釈と共に述べた – アプリケーションの迅速な改修 – 環境への迅速な展開 – リソース増減や運用管理を容易にする
- 15. DevOps
- 20. 違います！
- 21. DevOpsとは何か？ • 基本概念 • 開発(Dev)と運用(Ops)でビジネスの成果を継続的に達 成できるように、お互いが協力しようという文化と思想 – 注：プロダクト開発手法ではない – 自動化だけの話でもない。 • これがDevOpsだという明確な答えはない • あるべき姿 – ゴールの共有 – お互いの協力 – ツールの活用
- 23. DevOpsとビジネス • 小さくはじめて、小さい成功を積み上げる いきなり大きくはじめても、議論だけで終わる • 市場の変化はすごく早い。これに対応するためにはビジ ネスの協力も絶対的に必要 BIZ Dev Ops 互いに分離した役割ではなく、どういっ たものを想定したビジネスなのか、どう 使わせるのかを全員で共有していく必要 がある learn build measure 顧客価値最大化 互いの協力
- 24. DevOpsという偶像 • DevOpsに実体はない – 開発と運用が協力する文化 • DevOpsの本質は、Continues Delivery – 継続的に「価値」を届け続けることが出来るか そのために開発と運用の協力 • WFだろうとアジャイルだろうと関係はないが、 近年はそのDeliveryスピードを求められるため、 結果的にアジャイルが向いているというだけ
- 25. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
- 27. クラウド時代のインフラストラクチャ • 例：CDP autoscaleパターン http://aws.clouddesignpattern.org/index.php/CDP:Scale_Out%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 要件 • 負荷によって性能を 上下させたい 特徴 • アプリケーションは 負荷に応じて処理能力を変化 • サーバを作って壊しやすいよ うにサーバは状態を持たない • システム全体の監視から システム構成変更のトリガー を引く
- 28. クラウド時代のインフラストラクチャ • クラウドインフラ – ソフトウェアと同じように扱える – 物理的設置情報や配線などは気にしない – サーバの構築は、GUI/CUI(API)で可能 – パブリッククラウドの場合 • ハードの調達は不要 • 従量課金
- 29. クラウド時代のインフラストラクチャ ２つの手法 • Infrastructure as code • Immutable Infrastructure
- 30. クラウド時代のインフラストラクチャ • Infrastructure as code 一言で言えば、 「サーバの構成管理を実行可能なスクリプトで」 従来の構成管理 Excel これからの構成管理 実行可能スクリプト
- 31. クラウド時代のインフラストラクチャ 問：なぜInfrastructure as codeが必要か？ 大量のサーバを何度も作成する必要がある 1. VM作成 2. ユーザ作成 3. ミドルインストール 4. アプリ配備 5. サービススタート 自動化しないと辛い 解:自動化するためには、実行可能なコードが必要
- 32. クラウド時代のインフラストラクチャ • Infrastructure as code – メンテが辛い/されないexcelから、動いて確認出来るコード ベースの世界 • インフラのコード化 – サーバの構築 » Aws,Azure,GCE,OpenStack…etc – アプリ／ミドルのインストール » Chef,puppet,ansible…etc • インフラのテストのコード化 – Serverspec インフラ（サーバ）の構築とテストの自動化が可能
- 33. クラウド時代のインフラストラクチャ • サーバの構築 – 例えばAWSでサーバ作るとこれくらいのコード – プログラムなのでループも再実行も自由自在 大量作成や環境ごとの構築でも同じ環境を作れる – プログラムなので自動化可能
- 34. クラウド時代のインフラの管理 • アプリ／ミドルのインストール – Provisioning Framework • Chef • Puppet • ansible これらのツールは、”処理”ではなく、“状態”を記述する • ChefのRecipeの例 • httpdをインストールしろ／されている状態を作れという指示で あり、具体的な処理手順（方法）ではない • 再実行しても想定する状態が変わらない ＝＞ 冪等性
- 35. クラウド時代のインフラの管理 • インフラのテストのコード化 – Testing Framework • Serverspec サーバの“状態”をテストする – Serverspeceのコード例 • Httpdのパッケージがインストールされているかを確認 • 他にファイルの有無の確認やサービスの状態の確認なども可 能
- 36. クラウド時代のインフラの管理 • Provisioning frameworkの導入の効果 – 環境構築手順はソースコードとする • コードに記述することで暗黙知の排除 • コードをメンテすれば良いので手順書不要 • コードで書かれているのでCIが可能 – CIで環境作成、テスト、環境削除が自動実行 • ソースコードなので、版数管理可能 – アプリケーションの版数と合わせることで、 適用環境が明確 – 好きな版数の環境(状態）をいつでも誰でも構築可能
- 39. Immutable Infrastructure • Immutable Infrastructure & Disposable Component 不変インフラと廃棄可能コンポーネント • 作ったサーバが、運用に入ったあとどうゆう状態になっ ているか分からないことが多い • サーバの状態管理がめんどくさいなら、 しなければいいじゃないというアプローチ • サーバの状態管理 ex)パッチの適用状況や動作しているアプリケーション の版数管理、ステートデータの扱い http://chadfowler.com/blog/2013/06/23/immutable-deployments/
- 40. Immutable Infrastructure Immutable Infrastructureを活用したアップデート • Blue Green deployment – Provisioning Framework等を使って新しい環境を作る – 新しい環境にアクセスするようにLBなどを切り替える – 新しい環境に問題があった場合は、古い環境へEBを 切り替えることでRollback 40 http://martinfowler.com/bliki/BlueGreenDeployment.html
- 41. Immutable Infrastructure • Immutable Infrastructureの問題点 – 作って壊すを繰り返すと、BareMetalやVMでは遅い – アプリケーションが使わないOSに含まれるコンポー ネントのメンテナンスが手間 開発者はアプリケーションを動かしたいだけ
- 42. コンテナ型仮想化
- 44. コンテナ コンテナ型仮想化 ハードウェア ミドル アプリ OS(linux) コンテナ ミドル アプリ コンテナ ミドル アプリ コンテナ型仮想化 • 特徴 – I/O エミュレーション不要 – ファイルシステムの隔離 – オーバヘッドほとんどない
- 45. コンテナ型仮想化 • メリット – VMに比べて起動が高速（プロセスの起動のみ） – メモリの使用量が少ない • デメリット – コンテナそのまま使うと複雑すぎて辛い（LXCとか） – 他コンテナのリソース食いの影響を受けやすい 特にI/O回り(一応、CPU,mem,DISK制限はできるけど・・・）
- 46. Docker コンテナ型仮想化
- 47. Docker • Docker社（旧dotCloud)が提供する クラウドサービスのOSS • OSS公開は2013年4月 • 実装はGo言語 • Linuxカーネルのコンテナライブラリを活用 使い勝手が大幅up • 出て半年くらいで大流行。調子にのって社名変更 • PaaSに新たな地平を開いた • 手元の環境とPaaSの環境の違いによって、バグが出る のは大変つらい→依存コンポを環境ごとにdeploy
- 48. Docker • 特徴 – Linuxカーネルの機能に依存 – ホストもゲストもLinuxのみ – ホスト／ゲストは異なるディストリで良い – 1コンテナ1プロセス – 差分管理ファイルシステム
- 49. Docker • メリット – OSの機能が使える（yum,apt-getなど） – イメージの作成もコードで記述 – イメージを持ち運べる。PC⇔AWS⇔GCE – コンテナイメージの差分管理により、 再構築、分岐が容易（マージは無理） OS（の塊）のソフトウェア化
- 50. Docker • デメリット – アーキテクチャの変更が必須 – コンテナの中にOS素材は入っているが、バックグラ ウンドプロセスはなし。フォワグランド１プロセス と標準入出力のみ – コンテナのIPアドレスは不定 ホストOSからの仮想NICと ポートマッピング – ホスト側からコンテナ内の プロセスは丸見え コンテナ ブリッジ
- 51. Docker コンテナイメージを作成 docker build -t httpd . コンテナ起動 docker run -t http Dockerfileを用意 ←行単位で差分管理されるので、 変更があった場合は変更箇所から の再ビルドのみで済む
- 52. Docker • Dockerを使うと両方出来る – クラウドネイティブアプリケーションによる改革 – クラウド時代のインフラストラクチャ いつやるか？ もう遅いからさっさとやりましょう
- 53. Docker界隈の動き • Dockerに対応したIaaS出現中 – AWS – GCE – Azure – Disitalocian • 業界動向 – Openstackがdockerサポート表明（nova driver） – RHがRHEL7,Atomic HostでDockerをサポート – AWS ECSの提供開始（2015/01 β） – RedhatのPaaS（OpenShift v3）でdocker対応 – Docker社による商用サポートの開始（6月から） – Cloud Foundry がDockerに対応 – Dockerに最適化されたCoreOSの登場 – Googleのサービスは独自コンテナで運用（20億/週）
- 54. クラウド時代の運用 • アプリケーションが変わりました – tweleve factor app • インフラの構築が変わりました – Infrastructure as code • インフラの運用が変わりつつあります – Immutable Infrastructure あと、変わらなければならないのは人とプロセスです
- 55. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
- 56. エンジニア生存方法 • 意識改革 – 新しい技術がたくさん来ている – クラウドによってインフラの常識が変化 – ビジネス想像のためにアプリケーションアーキテク チャが変わりつつある
- 57. エンジニア生存方法 • クラウドエンジニア – 主にサービスの開発運用を行っているエンジニア – ビジネスを創造している – ビジネスの収益を支えるサービスを作ってる • エンタープライズエンジニアとの違い – DevOpsな文化 – 自分で考えてなんとかしようと言う主体性 – サービス運用による責任感
- 58. エンジニア生存方法 • 視野を広く、情報収集と人脈を作ろう • 例えば – 社外勉強会に参加しよう – 情報収集して、手を動かし、ブログを書こう – 広い視野の武器（知識と経験）を持とう
- 60. エンタープライズ開発 新潮流 • 日経コンピュータとItproに 載った記事の総集編 • 今回紹介した内容の以下が網羅、 – Twelve-Dactor App – Immutable Infrastructure – Docker • お値段：2918円（税込）
- 61. おわり