超分散システムを統治せよ! マイクロサービス開発 展開のエッセンス 日本アイ ビー エム株式会社 IBM クラウド事業本部エグゼクティブ IT スペシャリスト 樽澤広亨
自己紹介 IBM クラウド事業本部アーキテクト ISO IEC JTC1/SC38 専門委員クラウド国際標準策定に従事過去米 IBM ソフトウェア開発研究所ソフトウェア製品開発エンジニア IBM ソフトウェア グループエバンジェリスト, 技術営業, etc.
このセッションについて 目的 マイクロサービス適用時の設計のポイントを知る サービス メッシュ最適化の方策を知る
内容 マイクロサービス概要 サービスの設計 Istio によるサービス メッシュ最適化 まとめ
マイクロサービス概要
マイクロサービス概要 クラウド ネイティブ アプリケーション 開発 運用のベスト プラクティス 動機 アプリケーション個別の保守を可能にする柔軟なモジュラー構造 ( サービス ) の実現対象分野 アーキテクチャー 開発 運用チーム フォーメーション システム ライフサイクル
マイクロサービス アークテクチャー 小さなサービスの組合せでアプリを構成 各サービスは独立したコンテナで稼動 各サービスは軽量プロトコルで連携 各サービスはそれぞれ個別に自動デプロイ 各サービスはそれぞれ最適なプログラミング言語で実装 各サービスはそれぞれ最適なデータ ストレージを利用
マイクロサービス アーキテクチャー全体像 モノリス (1 枚岩 ) アプリケーション構造 マイクロサービスに基づいたアプリケーション構造 ユーザーインターフェース ドメイン サービス アプリモジュール プログラム プログラムプログラムプログラム Backend for Frontend (API Gateway) ドメイン サービス リポジトリー サービス リソース リソース 8
クラウド ネイティブ コンピューティング : 開発 運用の流れと役割 局面 ドメイン分析 設計 ビジネス要件の洗い出し ドメイン モデルの設計 開発 コーディング ビルド テスト リリース デプロイ 運用 アプリケーション監視 基盤監視 ログ運用 イベント統合管理 繰り返し 役割 ドメインスペシャリスト ICT アーキテクト SW エンジニア ICT アーキテクト Site Reliability エンジニア SW エンジニア 継続的デリバリー (Continuous Delivery, CD) 手法 ドメイン駆動設計 (Domain Driven Design, DDD) 継続的インテグレーション (Continuous Integration, CI) サイト リライアビリティ エンジニアリング (Site Reliability Engineering, SRE) スクラム等
サービスと開発 運用チーム フォーメーションの関係 コンウェイの法則 : システム構造は, プロジェクト体制を反映する マイクロサービス : ビジネス目的に基づいてチーム編成 システムは 独立して置き換え可能なサービスで構成される Monolith 保守時全システムに対する作業が必要 Microservices 保守時各サービスの置き換えが可能 ビジネス要件 開発運用プロジェクト体制 ICT システム構造 ビジネス要件 開発運用プロジェクト体制 ICT システム構造 要件 実装 ユーザー インターフェース チーム アプリケーション サーバー チーム 開発運用 開発運用 ユーザーインターフェース層 密結合 アプリケーション層 要件 #1 要件 #2 サービス #1チームサービス #1 実装開発運用 サービス #2チーム実装 開発運用 疎結合 サービス #2 疎結合 DB チーム 開発運用 DB 層 密結合 要件 #3 サービス #3チーム実装 開発運用 疎結合 サービス #3 凡例 ユーザー インターフェース スペシャリスト アプリケーション サーバー スペシャリスト DB スペシャリスト ユーザー インターフェース ページとプログラム アプリケーション サーバー プログラム DB アクセス プログラム 密結合 疎結合
Spotify のチーム編成 トライブ トライブ スクワッド スクワッドスクワッドスクワッドスクワッド スクワッドスクワッドスクワッド チャプター チャプター チャプター チャプター チャプター チャプター チャプター チャプター チャプター チャプター ギルド
マイクロサービス 始める? 始めない? 基本方針対象システムが複雑 : マイクロサービス化を検討する対象システムが単純 : マイクロサービス化には向いていない 単純なシステムのマイクロサービス化は 高いコストに帰結 ~ MicroservicePremium 自動デプロイメント, 分散システム運用監視, 結果整合性, ビジネス分析, 生産性 モノリス マイクロサービス 複雑さ
マイクロサービス適用に先立つ懸案事項 マイクロサービス適用の結果 超分散システム化!? 様々な懸案の解決が求められる サービス設計 構造 粒度 ~ サービス化のすすめ方 データ モデル トランザクション サービス メッシュ最適化 ルーティング サービスのリリース テスト 耐障害性 テレメトリー
サービスの設計
サービスの構造 サービス 実装すべきビジネス要件 インターフェースとモデルを包含する 在庫管理 在庫エンドポイント 配送エンドポイント 製品在庫 配送 インターフェースプログラミング インターフェース モデルビジネス データ
サービスのレイヤー構造例 Backend for Frontend (API Gateway) ゲートウェイ Façade API エンド ポイント データ / プロトコル変換 サービス アグリゲーション ドメイン サービス ビジネス ロジック 業務処理実装 リポジトリー サービス リソース アクセス データ, メッセージングへのアクセス リソース
サービス化の進め方 : ビジネス指向と繰り返し開発 前提 / 文脈 素早いビジネス立上げ 柔軟なビジネス変更 1 回の分析 設計でサービス最適化は不可能 方針 ビジネス指向 開発 運用の繰り返し 方策 期待される効果 業務観点でサービスの切り出し ドメイン駆動設計 ビジネスのローンチ & トランスフォーメーション アジャイル開発 サービス粒度の最適化
サービス化の進め方 :BFF/API Gateway の粒度 Backend for Frontend (BFF) サービス アグリゲーション API Gateway (API GW) API エンドポイント データ & プロトコル変換 2 つの観点より設置単位を検討 ユースケース クライアントのタイプあるいは種類
サービス化の進め方 :BFF/API Gateway の粒度 ユースケースの観点での検討 1 ユースケース毎に 1 BFF/API GW を推奨 複数ユースケースに 1 BFF/API GW を設置した場合 粒度が大きくなり メンテナンスのボトルネックとなる ユースケース 1 ユースケース 2 ユースケース 3 Backend for Frontend (API Gateway) ユースケース 1 BFF/API GW ユースケース 2 BFF/API GW ユースケース 3 BFF/API GW ドメイン サービス
サービス化の進め方 :BFF/API Gateway の粒度 クライアントのタイプあるいは種類の観点での検討 原則クライアント種類毎に 1 BFF/API GW 設置を推奨 クライアント タイプ毎に 1 BFF/API GW 設置した場合 BFF/API GW の種類が多くなりすぎ メンテナンスのボトルネックになる懸念 One-size-fits-all の場合 BFF/API GW が大きくなりすぎ メンテナンスのボトルネックになる懸念 クライアント タイプ毎クライアント種類毎 One-size-fits-all BFF API GW BFF API GW BFF API GW BFF API GW BFF API GW BFF API GW BFF/API GW BFF/API GW BFF/API GW BFF/API GW
データ アクセス サービスを介してデータベースにアクセスする マイクロサービス スタイル 非マイクロサービス スタイル サービス サービス サービスサービスサービスサービスサービス DB サービス DB DB DB DB のメンテナンスの影響を最小化し サービスへの影響を極力排除する
トランザクション処理原則ローカル トランザクション処理 Local TX : ローカル トランザクション Global TX : グローバル トランザクション マイクロサービス スタイル 非マイクロサービス スタイル Local TX Local TX Global TX サービス Local TX サービス サービス サービス DB サービス DB DB サービス DB DB DB 実装をシンプルに保ち スピーディな障害対応に備える サービス間の疎結合を維持する
トランザクション処理 : 複数リソースの同期処理 Saga パターン 複数リソースの同期を取るデザイン パターン ローカル トランザクション, イベント, 補償トランザクションを活用 2. イベント伝播 正常系処理の流れ 4. イベント伝播 1.DB 処理 3.DB 処理 5.DB 処理 サービス DB サービス DB サービス DB d.db 処理 ( キャンセル ) b.db 処理 ( キャンセル ) 不具合 a. キャンセル処理呼び出し c. イベント伝播 ( キャンセル処理呼び出し ) 異常系処理の流れ ~ 補償トランザクション サーバーレス (FaaS) のイベント駆動処理に最適な処理パターン
データ & トランザクション処理 : CQRS とイベント ソーシング Command Query Responsibility Segregation コマンド ( データ更新 ) とクエリ ( データ参照 ) に 異なるデータ モデルを利用 イベント ソーシング 一連の業務情報をイベント ストアに書き込む 適宜ビューを生成し参照処理に充てる パフォーマンス データモデル最適化 アクセス制御 監査性 証跡性
データ & トランザクション処理 : CQRS とイベント ソーシング CQRS パターン 更新系アプリ 更新系処理はコマンドを利用 参照系処理はクエリーを利用 参照系アプリ 更新系処理では全てのイベントをイベント ストアに格納 コマンド検証 ドメイン ロジック データ永続化 クエリー Data Transfer Object 参照用に最適化されたビューを基に高速に検索処理 在庫情報 受注情報 2018/03/10, 顧客 A, L 社パソコン, 数量 1, 2018/03/11, 顧客 B, Z 社マウス, 数量 1, イベント ストア イベント ソーシング パターン ビュー 適宜 イベント ストアを基にビューを生成 同期
データ & トランザクション処理 : データをどこに配置? 参照系データと更新系データの分離の実装モデル データ参照はキャッシュを利用 アプリケーション キャッシュ エンド ユーザー クラウド データ更新はマスター DB に適用 お客様データセンター DB DB とキャッシュ間は適宜同期例 ) 更新の都度 一定の更新件数毎 インターバル セキュア マスター DB を安全なお客様データセンターに配備パフォーマンス最適化 高頻度の検索要求にはクラウド上のキャッシュで素早く処理 クラウド -DC 間のネットワークは 比較的低頻度の更新処理に限定
Istio によるサービス メッシュ最適化
サービス メッシュ マイクロサービス アーキテクチャーにおけるサービス間ネットワーク 課題 ルーティング? サービスのリリース? テスト? 耐障害性? テレメトリー?
Istio マイクロサービスの相互接続, 管理, セキュリティのためのオープンプラットフォームサービス メッシュ最適化のソリューション オープンソース コミュニティ開発 マルチ プラットフォーム サポート アプリケーション非依存
Istio の主要な機能サービスの継続的なリリース ブルー / グリーン デプロイメント カナリア リリース サービス間通信の認証 認可 暗号化 相互 TLS 信頼性検証のための End-to-End テスト支援 フォールト インジェクション ( カオス エンジニアリング ) システム障害の影響最小化 サーキット ブレーカー 統合ダッシュボードログ, トレース, メトリクスの一覧監視 統合ダッシュボード
アーキテクチャー Envoy の構成管理 CLI $istioctl 管理 コントロール プレーン Pilot Mixer Citadel Mutual TLS による認証 サイドカー型プロキシー 管理作業 Pod Pod Pod Envoy アクセス制御 ポリシー設定等 Pod Pod Pod Envoy HTTP grpc TCP サービス A 実装 サービス A HTTP, grpc, TCP サイドカー型プロキシー サービス B 実装 サービス B
カナリア リリース 1.90% トラフィック転送 現行本番環境 エンド ユーザー ロードバランサー (Envoy) 1.10% トラフィック転送 4.100% トラフィック転送 次期本番環境 3. 本番環境完全移行 2. 試行 & フィードバック 次期 / 代替リリースの試行とフィードバック
フォールト インジェクション : 遅延 応答時間の遅延 1. リクエスト 2. リクエスト Envoy 3. 意図的な遅延 ネットワーク レイテンシーをシミュレート 4. リクエスト 意図通りの動作か確認 7. レスポンス 6. レスポンス 5. レスポンス ネットワーク遅延障害時の End-to-end テストを容易に実施可能
フォールト インジェクション : エラー コードの返信 エラーの受信 1. リクエスト 4. エラーの返信 2. リクエスト 3. エラーの返信 Envoy 障害をシミュレーション 意図通りの動作か確認 意図的にエラー コードを返す ネットワーク エラー発生時の End-to-end テストを容易に実施可能
サーキット ブレーカー サービス呼び出し失敗時の影響を最小化するデザイン パターン 超分散システムでは, サービス呼出失敗が大規模障害に繋がる 想定される影響 応答時間遅延 システム リソースのブロック システム全体のダウン 解決策 : サーキット ブレーカー 一定回数のサービス呼び出し失敗以降 サービス呼出元に即座にエラーを返す 期待される効果 応答時間短縮 システム リソース ブロックの排除
サーキット ブレーカー 動作フロー サービス呼出障害 ブレーカーオープン ブレーカークローズ 即座にエラーを返す サーキット ブレーカー (Envoy) 1. リクエスト 2. リクエスト 4. エラー 3. タイムアウト 障害 エラー回数が閾値に達した場合 サーキット ブレーカー (Envoy) 1. リクエスト a. ヘルスチェック 2. エラー 障害 ヘルス チェック試行 障害回復を確認できた場合 サーキット ブレーカー (Envoy) 1. リクエスト 2. リクエスト 4. レスポンス 3. レスポンス
まとめ
まとめ マイクロサービスは 複雑なシステム開発 運用に効果的 マイクロサービス開発 運用にあたっては サービス設計に加え, サービス メッシュの最適化が求められる Istio は, サービス メッシュ最適化のソリューション
ワークショップ セッション および資料は IBM またはセッション発表者によって準備され それぞれ独自の見解を反映したものです それらは情報提供の目的のみで提供されており いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく またそのような結果を生むものでもありません 本講演資料に含まれている情報については 完全性と正確性を期するよう努力しましたが 現状のまま 提供され 明示または暗示にかかわらずいかなる保証も伴わないものとします 本講演資料またはその他の資料の使用によって あるいはその他の関連によって いかなる損害が生じた場合も IBM は責任を負わないものとします 本講演資料に含まれている内容は IBM またはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも IBM ソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく またそのような結果を生むものでもありません 本講演資料で IBM 製品 プログラム またはサービスに言及していても IBM が営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません 本講演資料で言及している製品リリース日付や製品機能は 市場機会またはその他の要因に基づいて IBM 独自の決定権をもっていつでも変更できるものとし いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません 本講演資料に含まれている内容は 参加者が開始する活動によって特定の販売 売上高の向上 またはその他の結果が生じると述べる または暗示することを意図したものでも またそのような結果を生むものでもありません パフォーマンスは 管理された環境において標準的な IBM ベンチマークを使用した測定と予測に基づいています ユーザーが経験する実際のスループットやパフォーマンスは ユーザーのジョブ ストリームにおけるマルチプログラミングの量 入出力構成 ストレージ構成 および処理されるワークロードなどの考慮事項を含む 数多くの要因に応じて変化します したがって 個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません 記述されているすべてのお客様事例は それらのお客様がどのように IBM 製品を使用したか またそれらのお客様が達成した結果の実例として示されたものです 実際の環境コストおよびパフォーマンス特性は お客様ごとに異なる場合があります IBM IBM ロゴ ibm.com IBM Cloud は 世界の多くの国で登録された International Business Machines Corporation の商標です 他の製品名およびサービス名等は それぞれ IBM または各社の商標である場合があります 現時点での IBM の商標リストについては www.ibm.com/legal/copytrade.shtml をご覧ください