Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウドネイティブなアーキテクチャを設計する次世代の現場力

Shingo.Kitayama
September 28, 2018

 クラウドネイティブなアーキテクチャを設計する次世代の現場力

”Developers Summit 2018 KANSAI”で発表した資料です。
https://event.shoeisha.jp/devsumi/20180928

Shingo.Kitayama

September 28, 2018
Tweet

More Decks by Shingo.Kitayama

Other Decks in Technology

Transcript

  1. の役割はクラウドの抽象化だけでなく、リソースマネージメントを行う はクラウドの アプリケーションプロセス アプリケーションコンテナ システムコール プロセス 管理 メモリ 管理 デバイス管理

    プロセス 間通信 割り込み 管理 コンテナ スケジューリング メモリ 管理 デバイス管理 コンテナ 負荷分散 コンテナ 死活監視 アプリケーションは が提供する機能を前提として開発される アプリケーションはクラウドが提供する機能を前提として開発される
  2. コンテナは仮想化の延長ではない 仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine

    Lib OS App Lib App Lib App Lib アプリケーション の起動に アプリケーション の起動に の起動 プロセスの起動
  3. コンテナは仮想化の延長ではない 仮想化とコンテナ Infrastructure Hypervisor OS App Infrastructure OS Container Engine

    Lib OS App Lib App Lib App Lib だけだと、 クラウドネイティブが分かりずらい 「結局、 とコンテナが起動する速さの違い?」 ということで。少し違う視点で見てみる
  4. クラウドネイティブにおける柔軟なリソース配置 仮想化とコンテナ OS App Lib App Lib App Lib 専用の

    仮想マシン OS App Lib 専用の仮 想マシンイメージ 標準化された コンテナイメージ 移行するためには コンバーターが必要 どこでも移行可能
  5. クラウドネイティブを実現するためのツールも、利用対象によって意味合いが異なる クラウドロックインからの開放 ・ベンダーロックイン ・自由な の選択 レイヤの依存により、各ベンダーごとに仮想 マシンの作成方法が変わる。その分、どの でも利用 できるため、設定の自由度が高い。 ・ベンダーロックインの開放

    ・ の依存 コンテナエンジン を利用することによって、アプリ ケーションそのものをどこでも実行することができる。ただ し、 が限定されるため、 などには専用 が必要。 ベンダーごとに異なる設定や、個別のカスタマ イズを重視した設定をコードに反映することで、 クラウドネイティに必要な柔軟性やスピード、 品質に対応する。 ベンダーロックインを避けるコンテナの特性を活 かし、オーケストレーションの機能によって、クラ ウドネイティブが必要とするスピードと品質に対 応する。
  6. カスタム運用の回避と回復性の高い設計が重要。 クラウドネイティブなシステム運用 正常稼働 障害検知 状態確認 復旧作業 正常確認 正常稼働 障害検知 動的復旧

    手作業 不具合修正 再構築 正常確認 自己修復 自動作業 個別対応 クラウドネイティブな運用 ・各ベンダーの運用作業を統一 ・カスタム運用を極小化 クラウドネイティブな運用 ・自動修復 ・動的リソース調整
  7. カスタム運用の回避と回復性の高い設計が重要。 クラウドネイティブなシステム運用 正常稼働 障害検知 状態確認 復旧作業 正常確認 正常稼働 障害検知 動的復旧

    手作業 不具合修正 再構築 正常確認 自己修復 自動作業 個別対応 クラウドネイティブな運用 ・各ベンダーの運用作業を統一 ・カスタム運用を極小化 クラウドネイティブな運用 ・自動修復 ・動的リソース調整 複雑な運用に関しては、 で解決。 マネージドサービス を活用 カスタム運用そのものを 極小化する一歩へ。 「自動化」 「自律化」
  8. カスタム運用を減らすことで得られる効果 マネージドサービスの利点 実証済みのソリュー ションによる、導入の 迅速化と容易化 日常業務における リソース運用 からの解放 予測可能で経済的 な価格設定による

    コスト削減 迅速かつ 費用対効果の高い 拡張 継続的な監視で ビジネスを保護 マネージドサービスは運用ノウハウをサービス化したもの。 自律化されたシステムを利用。
  9. マイクロサービス化の流れ モノリシックとマイクロサービス ディスパッチャー プレゼンテーション ビジネスロジック 機能 機能 機能 データアクセス サービス

    機能 データアクセス サービス 機能 データアクセス サービス 機能 データアクセス 疎結合 マイクロサービス化することが 必ずしも正義ではない ※結構大変:どの単位で分割するの ただし、モノリシックなロジックを分割し リリースのリスクを最小化する意識は必要
  10. アプリマイグレーション Application Database Load Balancer KVS Database を最後に切り替える Load Balancer

    KVS ここまでは、ただのクラウド移行。 サービスメッシュ を活用し、 サービス間を管理する。 「完璧なリリース」 「アクセスに応じたデプロイ」 どこでも同じリリース方式
  11. サービスの疎結合と独立性を徹底する サービスメッシュの利点 サービス切り替えの 迅速化と容易化 日常業務における サービスリリース作業 からの解放 予測可能で経済的 な価格設定による コスト削減

    言語にとらわれず、 サービスリリース機能 そのものの拡張 継続的な監視で ビジネスを保護 サービスメッシュはリリースにおける運用リスクを回避
  12. チームワーク 意識改革 を育成する To accelerate the delivery of our customer’s

    innovative ideas, and create infectious enthusiasm for building applications the Red Hat Way, by leveraging community-powered innovation to deliver an outstanding labs experience.