Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fcp

725 views

Published on

某所向け資料の公開版

Published in: Technology
  • Be the first to comment

Fcp

  1. 1. たかはし なおと 生存戦略 クラウド時代をエンジニアとして生き残るために
  2. 2. 注意! この資料は個人の見解であり、 所属する組織の 公式見解ではありません
  3. 3. • たかはしなおと • TwitterID: tnaoto • クラウド基盤の開発
  4. 4. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
  5. 5. ICTの役割変化
  6. 6. ICTの役割変化 http://jp.fujitsu.com/group/fri/downloads/events/fri/forum2010_honjyo.pdf
  7. 7. http://jp.fujitsu.com/group/fri/downloads/events/fri/forum2010_honjyo.pdf
  8. 8. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
  9. 9. アプリケーションアーキテクチャの変貌 戦略的投資は、試行錯誤、かつ、スピード勝負 • クラウド上でアプリケーションの運用 • メリット – ハードウェア不要 – 必要なリソースは必要な分だけ • デメリット – いままで運用してきたアプリケーションは要回収 – “秘伝のタレ”が使えない
  10. 10. ICTの役割変化 SoRとSoE • SoR:System of Record – 記録系業務システム • SoE:System of Engagement – SNSのようなヒトの関係性を表すシステム
  11. 11. クラウドによる変化 • 大規模分散処理 – Hadoop, CEPなど • オートスケールアウト/スケールイン – 動的負荷分散 • SDN(software Defined Network) – ネットワーク経路検索の動的プログラミング • 開発手法の変革 – アジャイルの普及/DevOps
  12. 12. アプリケーションアーキテクチャの変貌 • PaaS – クラウドネイティブアプリケーションの代表的な例 • 特徴 – 強い型決め – 開発者は、アプリケーションの開発にだけ注力 – OS、ハードは気にしなくて良い、 もしくは、気にすることが出来ない アプリケーションのアーキテクチャが変わる
  13. 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. 14. THE TWELVE-FACTOR APP • 日経コンピュータ 9/18 号 • 日経ITPro http://itpro.nikkeibp.co.jp/atcl/column /14/110900092/ • 12個のプラクティスを3つに分類 エンタープライズはどうするべきかを、 オリジナルの解釈と共に述べた – アプリケーションの迅速な改修 – 環境への迅速な展開 – リソース増減や運用管理を容易にする
  15. 15. DevOps
  16. 16. DevOps • トレンド検索の結果 • 近年徐々に増加。日経コンピュータなどでも度々出典
  17. 17. よくある言葉 DevOpsやりたい
  18. 18. DevOpsのために 自動化します
  19. 19. えー Redmine使ってるか ら、うちはDevOps してます!
  20. 20. 違います!
  21. 21. DevOpsとは何か? • 基本概念 • 開発(Dev)と運用(Ops)でビジネスの成果を継続的に達 成できるように、お互いが協力しようという文化と思想 – 注:プロダクト開発手法ではない – 自動化だけの話でもない。 • これがDevOpsだという明確な答えはない • あるべき姿 – ゴールの共有 – お互いの協力 – ツールの活用
  22. 22. DevOpsの原点 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr インフラ自動化 すべてを版数管理 ビルドとデプロイを1ステップ 機能分けフラグ 共通メトリック IRCとIM(Instant Messenger) 尊敬 信頼 障害に向き合う Culture Tools 非難しない
  23. 23. DevOpsとビジネス • 小さくはじめて、小さい成功を積み上げる いきなり大きくはじめても、議論だけで終わる • 市場の変化はすごく早い。これに対応するためにはビジ ネスの協力も絶対的に必要 BIZ Dev Ops 互いに分離した役割ではなく、どういっ たものを想定したビジネスなのか、どう 使わせるのかを全員で共有していく必要 がある learn build measure 顧客価値最大化 互いの協力
  24. 24. DevOpsという偶像 • DevOpsに実体はない – 開発と運用が協力する文化 • DevOpsの本質は、Continues Delivery – 継続的に「価値」を届け続けることが出来るか そのために開発と運用の協力 • WFだろうとアジャイルだろうと関係はないが、 近年はそのDeliveryスピードを求められるため、 結果的にアジャイルが向いているというだけ
  25. 25. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
  26. 26. クラウド時代の インフラストラクチャ
  27. 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. 28. クラウド時代のインフラストラクチャ • クラウドインフラ – ソフトウェアと同じように扱える – 物理的設置情報や配線などは気にしない – サーバの構築は、GUI/CUI(API)で可能 – パブリッククラウドの場合 • ハードの調達は不要 • 従量課金
  29. 29. クラウド時代のインフラストラクチャ 2つの手法 • Infrastructure as code • Immutable Infrastructure
  30. 30. クラウド時代のインフラストラクチャ • Infrastructure as code 一言で言えば、 「サーバの構成管理を実行可能なスクリプトで」 従来の構成管理 Excel これからの構成管理 実行可能スクリプト
  31. 31. クラウド時代のインフラストラクチャ 問:なぜInfrastructure as codeが必要か? 大量のサーバを何度も作成する必要がある 1. VM作成 2. ユーザ作成 3. ミドルインストール 4. アプリ配備 5. サービススタート 自動化しないと辛い 解:自動化するためには、実行可能なコードが必要
  32. 32. クラウド時代のインフラストラクチャ • Infrastructure as code – メンテが辛い/されないexcelから、動いて確認出来るコード ベースの世界 • インフラのコード化 – サーバの構築 » Aws,Azure,GCE,OpenStack…etc – アプリ/ミドルのインストール » Chef,puppet,ansible…etc • インフラのテストのコード化 – Serverspec インフラ(サーバ)の構築とテストの自動化が可能
  33. 33. クラウド時代のインフラストラクチャ • サーバの構築 – 例えばAWSでサーバ作るとこれくらいのコード – プログラムなのでループも再実行も自由自在 大量作成や環境ごとの構築でも同じ環境を作れる – プログラムなので自動化可能
  34. 34. クラウド時代のインフラの管理 • アプリ/ミドルのインストール – Provisioning Framework • Chef • Puppet • ansible これらのツールは、”処理”ではなく、“状態”を記述する • ChefのRecipeの例 • httpdをインストールしろ/されている状態を作れという指示で あり、具体的な処理手順(方法)ではない • 再実行しても想定する状態が変わらない => 冪等性
  35. 35. クラウド時代のインフラの管理 • インフラのテストのコード化 – Testing Framework • Serverspec サーバの“状態”をテストする – Serverspeceのコード例 • Httpdのパッケージがインストールされているかを確認 • 他にファイルの有無の確認やサービスの状態の確認なども可 能
  36. 36. クラウド時代のインフラの管理 • Provisioning frameworkの導入の効果 – 環境構築手順はソースコードとする • コードに記述することで暗黙知の排除 • コードをメンテすれば良いので手順書不要 • コードで書かれているのでCIが可能 – CIで環境作成、テスト、環境削除が自動実行 • ソースコードなので、版数管理可能 – アプリケーションの版数と合わせることで、 適用環境が明確 – 好きな版数の環境(状態)をいつでも誰でも構築可能
  37. 37. クラウド時代のインフラの管理 構築もインストールも テストもコード化 すべてCI出来る
  38. 38. クラウド時代のインフラの管理 クラウド時代のインフラは ソースコードの記述です コード読めない書けないと 仕事なくなります!
  39. 39. Immutable Infrastructure • Immutable Infrastructure & Disposable Component 不変インフラと廃棄可能コンポーネント • 作ったサーバが、運用に入ったあとどうゆう状態になっ ているか分からないことが多い • サーバの状態管理がめんどくさいなら、 しなければいいじゃないというアプローチ • サーバの状態管理 ex)パッチの適用状況や動作しているアプリケーション の版数管理、ステートデータの扱い http://chadfowler.com/blog/2013/06/23/immutable-deployments/
  40. 40. Immutable Infrastructure Immutable Infrastructureを活用したアップデート • Blue Green deployment – Provisioning Framework等を使って新しい環境を作る – 新しい環境にアクセスするようにLBなどを切り替える – 新しい環境に問題があった場合は、古い環境へEBを 切り替えることでRollback 40 http://martinfowler.com/bliki/BlueGreenDeployment.html
  41. 41. Immutable Infrastructure • Immutable Infrastructureの問題点 – 作って壊すを繰り返すと、BareMetalやVMでは遅い – アプリケーションが使わないOSに含まれるコンポー ネントのメンテナンスが手間 開発者はアプリケーションを動かしたいだけ
  42. 42. コンテナ型仮想化
  43. 43. 仮想化おさらい ハードウェア OS ミドルウェア アプリケーション ハードウェア ハイパーバイザ ミドル アプリ OS ミドル アプリ OS ミドル アプリ OS ハードウェア OS(kvmホスト) ミドル アプリ OS ミドル アプリ OS ミドル アプリ OS ハイパーバイザ 物理環境 vmware型 Linux KVM
  44. 44. コンテナ コンテナ型仮想化 ハードウェア ミドル アプリ OS(linux) コンテナ ミドル アプリ コンテナ ミドル アプリ コンテナ型仮想化 • 特徴 – I/O エミュレーション不要 – ファイルシステムの隔離 – オーバヘッドほとんどない
  45. 45. コンテナ型仮想化 • メリット – VMに比べて起動が高速(プロセスの起動のみ) – メモリの使用量が少ない • デメリット – コンテナそのまま使うと複雑すぎて辛い(LXCとか) – 他コンテナのリソース食いの影響を受けやすい 特にI/O回り(一応、CPU,mem,DISK制限はできるけど・・・)
  46. 46. Docker コンテナ型仮想化
  47. 47. Docker • Docker社(旧dotCloud)が提供する クラウドサービスのOSS • OSS公開は2013年4月 • 実装はGo言語 • Linuxカーネルのコンテナライブラリを活用 使い勝手が大幅up • 出て半年くらいで大流行。調子にのって社名変更 • PaaSに新たな地平を開いた • 手元の環境とPaaSの環境の違いによって、バグが出る のは大変つらい→依存コンポを環境ごとにdeploy
  48. 48. Docker • 特徴 – Linuxカーネルの機能に依存 – ホストもゲストもLinuxのみ – ホスト/ゲストは異なるディストリで良い – 1コンテナ1プロセス – 差分管理ファイルシステム
  49. 49. Docker • メリット – OSの機能が使える(yum,apt-getなど) – イメージの作成もコードで記述 – イメージを持ち運べる。PC⇔AWS⇔GCE – コンテナイメージの差分管理により、 再構築、分岐が容易(マージは無理) OS(の塊)のソフトウェア化
  50. 50. Docker • デメリット – アーキテクチャの変更が必須 – コンテナの中にOS素材は入っているが、バックグラ ウンドプロセスはなし。フォワグランド1プロセス と標準入出力のみ – コンテナのIPアドレスは不定 ホストOSからの仮想NICと ポートマッピング – ホスト側からコンテナ内の プロセスは丸見え コンテナ ブリッジ
  51. 51. Docker コンテナイメージを作成 docker build -t httpd . コンテナ起動 docker run -t http Dockerfileを用意 ←行単位で差分管理されるので、 変更があった場合は変更箇所から の再ビルドのみで済む
  52. 52. Docker • Dockerを使うと両方出来る – クラウドネイティブアプリケーションによる改革 – クラウド時代のインフラストラクチャ いつやるか? もう遅いからさっさとやりましょう
  53. 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. 54. クラウド時代の運用 • アプリケーションが変わりました – tweleve factor app • インフラの構築が変わりました – Infrastructure as code • インフラの運用が変わりつつあります – Immutable Infrastructure あと、変わらなければならないのは人とプロセスです
  55. 55. 今日お話すること • 目次 – ICTの役割の変貌 – クラウドネイティブアプリケーションによる改革 • アプリケーションアーキテクチャの変貌 • DevOps – クラウド時代のインフラストラクチャ • システムアーキテクチャの変貌 • インフラをCIする • Immutable Infrastructure – Docker – エンジニア生存方法
  56. 56. エンジニア生存方法 • 意識改革 – 新しい技術がたくさん来ている – クラウドによってインフラの常識が変化 – ビジネス想像のためにアプリケーションアーキテク チャが変わりつつある
  57. 57. エンジニア生存方法 • クラウドエンジニア – 主にサービスの開発運用を行っているエンジニア – ビジネスを創造している – ビジネスの収益を支えるサービスを作ってる • エンタープライズエンジニアとの違い – DevOpsな文化 – 自分で考えてなんとかしようと言う主体性 – サービス運用による責任感
  58. 58. エンジニア生存方法 • 視野を広く、情報収集と人脈を作ろう • 例えば – 社外勉強会に参加しよう – 情報収集して、手を動かし、ブログを書こう – 広い視野の武器(知識と経験)を持とう
  59. 59. DevOpsの要素再び http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr インフラ自動化 すべてを版数管理 ビルドとデプロイを1ステップ 機能分けフラグ 共通メトリック IRCとIM(Instant Messenger) 尊敬 信頼 障害に向き合う Culture Tools 非難しない
  60. 60. エンタープライズ開発 新潮流 • 日経コンピュータとItproに 載った記事の総集編 • 今回紹介した内容の以下が網羅、 – Twelve-Dactor App – Immutable Infrastructure – Docker • お値段:2918円(税込)
  61. 61. おわり

×