PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

いとはたけはな
4 years ago
Views:

1 超分散システムを統治せよ! マイクロサービス開発展開のエッセンス日本アイビーエム株式会社 IBM クラウド事業本部エグゼクティブ IT スペシャリスト樽澤広亨

2 自己紹介 IBM クラウド事業本部アーキテクト ISO IEC JTC1/SC38 専門委員クラウド国際標準策定に従事過去米 IBM ソフトウェア開発研究所ソフトウェア製品開発エンジニア IBM ソフトウェアグループエバンジェリスト, 技術営業, etc.

3 このセッションについて目的マイクロサービス適用時の設計のポイントを知るサービスメッシュ最適化の方策を知る

4 内容マイクロサービス概要サービスの設計 Istio によるサービスメッシュ最適化まとめ

5 マイクロサービス概要

6 マイクロサービス概要クラウドネイティブアプリケーション開発運用のベストプラクティス動機アプリケーション個別の保守を可能にする柔軟なモジュラー構造 ( サービス ) の実現対象分野アーキテクチャー開発運用チームフォーメーションシステムライフサイクル

7 マイクロサービスアークテクチャー小さなサービスの組合せでアプリを構成各サービスは独立したコンテナで稼動各サービスは軽量プロトコルで連携各サービスはそれぞれ個別に自動デプロイ各サービスはそれぞれ最適なプログラミング言語で実装各サービスはそれぞれ最適なデータストレージを利用

8 マイクロサービスアーキテクチャー全体像モノリス (1 枚岩 ) アプリケーション構造マイクロサービスに基づいたアプリケーション構造ユーザーインターフェースドメインサービスアプリモジュールプログラムプログラムプログラムプログラム Backend for Frontend (API Gateway) ドメインサービスリポジトリーサービスリソースリソース 8

9 クラウドネイティブコンピューティング : 開発運用の流れと役割局面ドメイン分析設計ビジネス要件の洗い出しドメインモデルの設計開発コーディングビルドテストリリースデプロイ運用アプリケーション監視基盤監視ログ運用イベント統合管理繰り返し役割ドメインスペシャリスト ICT アーキテクト SW エンジニア ICT アーキテクト Site Reliability エンジニア SW エンジニア継続的デリバリー (Continuous Delivery, CD) 手法ドメイン駆動設計 (Domain Driven Design, DDD) 継続的インテグレーション (Continuous Integration, CI) サイトリライアビリティエンジニアリング (Site Reliability Engineering, SRE) スクラム等

10 サービスと開発運用チームフォーメーションの関係コンウェイの法則 : システム構造は, プロジェクト体制を反映するマイクロサービス : ビジネス目的に基づいてチーム編成システムは独立して置き換え可能なサービスで構成される Monolith 保守時全システムに対する作業が必要 Microservices 保守時各サービスの置き換えが可能ビジネス要件開発運用プロジェクト体制 ICT システム構造ビジネス要件開発運用プロジェクト体制 ICT システム構造要件実装ユーザーインターフェースチームアプリケーションサーバーチーム開発運用開発運用ユーザーインターフェース層密結合アプリケーション層要件 #1 要件 #2 サービス #1チームサービス #1 実装開発運用サービス #2チーム実装開発運用疎結合サービス #2 疎結合 DB チーム開発運用 DB 層密結合要件 #3 サービス #3チーム実装開発運用疎結合サービス #3 凡例ユーザーインターフェーススペシャリストアプリケーションサーバースペシャリスト DB スペシャリストユーザーインターフェースページとプログラムアプリケーションサーバープログラム DB アクセスプログラム密結合疎結合

11 Spotify のチーム編成トライブトライブスクワッドスクワッドスクワッドスクワッドスクワッドスクワッドスクワッドスクワッドチャプターチャプターチャプターチャプターチャプターチャプターチャプターチャプターチャプターチャプターギルド

12 マイクロサービス始める? 始めない? 基本方針対象システムが複雑 : マイクロサービス化を検討する対象システムが単純 : マイクロサービス化には向いていない単純なシステムのマイクロサービス化は高いコストに帰結 ~ MicroservicePremium 自動デプロイメント, 分散システム運用監視, 結果整合性, ビジネス分析, 生産性モノリスマイクロサービス複雑さ

13 マイクロサービス適用に先立つ懸案事項マイクロサービス適用の結果超分散システム化!? 様々な懸案の解決が求められるサービス設計構造粒度 ~ サービス化のすすめ方データモデルトランザクションサービスメッシュ最適化ルーティングサービスのリリーステスト耐障害性テレメトリー

14 サービスの設計

15 サービスの構造サービス実装すべきビジネス要件インターフェースとモデルを包含する在庫管理在庫エンドポイント配送エンドポイント製品在庫配送インターフェースプログラミングインターフェースモデルビジネスデータ

16 サービスのレイヤー構造例 Backend for Frontend (API Gateway) ゲートウェイ Façade API エンドポイントデータ / プロトコル変換サービスアグリゲーションドメインサービスビジネスロジック業務処理実装リポジトリーサービスリソースアクセスデータ, メッセージングへのアクセスリソース

17 サービス化の進め方 : ビジネス指向と繰り返し開発前提 / 文脈素早いビジネス立上げ柔軟なビジネス変更 1 回の分析設計でサービス最適化は不可能方針ビジネス指向開発運用の繰り返し方策期待される効果業務観点でサービスの切り出しドメイン駆動設計ビジネスのローンチ & トランスフォーメーションアジャイル開発サービス粒度の最適化

18 サービス化の進め方 :BFF/API Gateway の粒度 Backend for Frontend (BFF) サービスアグリゲーション API Gateway (API GW) API エンドポイントデータ & プロトコル変換 2 つの観点より設置単位を検討ユースケースクライアントのタイプあるいは種類

19 サービス化の進め方 :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 ドメインサービス

20 サービス化の進め方 :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

21 データアクセスサービスを介してデータベースにアクセスするマイクロサービススタイル非マイクロサービススタイルサービスサービスサービスサービスサービスサービスサービス DB サービス DB DB DB DB のメンテナンスの影響を最小化しサービスへの影響を極力排除する

22 トランザクション処理原則ローカルトランザクション処理 Local TX : ローカルトランザクション Global TX : グローバルトランザクションマイクロサービススタイル非マイクロサービススタイル Local TX Local TX Global TX サービス Local TX サービスサービスサービス DB サービス DB DB サービス DB DB DB 実装をシンプルに保ちスピーディな障害対応に備えるサービス間の疎結合を維持する

23 トランザクション処理 : 複数リソースの同期処理 Saga パターン複数リソースの同期を取るデザインパターンローカルトランザクション, イベント, 補償トランザクションを活用 2. イベント伝播正常系処理の流れ 4. イベント伝播 1.DB 処理 3.DB 処理 5.DB 処理サービス DB サービス DB サービス DB d.db 処理 ( キャンセル ) b.db 処理 ( キャンセル ) 不具合 a. キャンセル処理呼び出し c. イベント伝播 ( キャンセル処理呼び出し ) 異常系処理の流れ ~ 補償トランザクションサーバーレス (FaaS) のイベント駆動処理に最適な処理パターン

24 データ & トランザクション処理 : CQRS とイベントソーシング Command Query Responsibility Segregation コマンド ( データ更新 ) とクエリ ( データ参照 ) に異なるデータモデルを利用イベントソーシング一連の業務情報をイベントストアに書き込む適宜ビューを生成し参照処理に充てるパフォーマンスデータモデル最適化アクセス制御監査性証跡性

25 データ & トランザクション処理 : CQRS とイベントソーシング CQRS パターン更新系アプリ更新系処理はコマンドを利用参照系処理はクエリーを利用参照系アプリ更新系処理では全てのイベントをイベントストアに格納コマンド検証ドメインロジックデータ永続化クエリー Data Transfer Object 参照用に最適化されたビューを基に高速に検索処理在庫情報受注情報 2018/03/10, 顧客 A, L 社パソコン, 数量 1, 2018/03/11, 顧客 B, Z 社マウス, 数量 1, イベントストアイベントソーシングパターンビュー適宜イベントストアを基にビューを生成同期

26 データ & トランザクション処理 : データをどこに配置? 参照系データと更新系データの分離の実装モデルデータ参照はキャッシュを利用アプリケーションキャッシュエンドユーザークラウドデータ更新はマスター DB に適用お客様データセンター DB DB とキャッシュ間は適宜同期例 ) 更新の都度一定の更新件数毎インターバルセキュアマスター DB を安全なお客様データセンターに配備パフォーマンス最適化高頻度の検索要求にはクラウド上のキャッシュで素早く処理クラウド -DC 間のネットワークは比較的低頻度の更新処理に限定

27 Istio によるサービスメッシュ最適化

28 サービスメッシュマイクロサービスアーキテクチャーにおけるサービス間ネットワーク課題ルーティング? サービスのリリース? テスト? 耐障害性? テレメトリー?

29 Istio マイクロサービスの相互接続, 管理, セキュリティのためのオープンプラットフォームサービスメッシュ最適化のソリューションオープンソースコミュニティ開発マルチプラットフォームサポートアプリケーション非依存

30 Istio の主要な機能サービスの継続的なリリースブルー / グリーンデプロイメントカナリアリリースサービス間通信の認証認可暗号化相互 TLS 信頼性検証のための End-to-End テスト支援フォールトインジェクション ( カオスエンジニアリング ) システム障害の影響最小化サーキットブレーカー統合ダッシュボードログ, トレース, メトリクスの一覧監視統合ダッシュボード

31 アーキテクチャー 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

32 カナリアリリース 1.90% トラフィック転送現行本番環境エンドユーザーロードバランサー (Envoy) 1.10% トラフィック転送 4.100% トラフィック転送次期本番環境 3. 本番環境完全移行 2. 試行 & フィードバック次期 / 代替リリースの試行とフィードバック

33 フォールトインジェクション : 遅延応答時間の遅延 1. リクエスト 2. リクエスト Envoy 3. 意図的な遅延ネットワークレイテンシーをシミュレート 4. リクエスト意図通りの動作か確認 7. レスポンス 6. レスポンス 5. レスポンスネットワーク遅延障害時の End-to-end テストを容易に実施可能

34 フォールトインジェクション : エラーコードの返信エラーの受信 1. リクエスト 4. エラーの返信 2. リクエスト 3. エラーの返信 Envoy 障害をシミュレーション意図通りの動作か確認意図的にエラーコードを返すネットワークエラー発生時の End-to-end テストを容易に実施可能

35 サーキットブレーカーサービス呼び出し失敗時の影響を最小化するデザインパターン超分散システムでは, サービス呼出失敗が大規模障害に繋がる想定される影響応答時間遅延システムリソースのブロックシステム全体のダウン解決策 : サーキットブレーカー一定回数のサービス呼び出し失敗以降サービス呼出元に即座にエラーを返す期待される効果応答時間短縮システムリソースブロックの排除

36 サーキットブレーカー動作フローサービス呼出障害ブレーカーオープンブレーカークローズ即座にエラーを返すサーキットブレーカー (Envoy) 1. リクエスト 2. リクエスト 4. エラー 3. タイムアウト障害エラー回数が閾値に達した場合サーキットブレーカー (Envoy) 1. リクエスト a. ヘルスチェック 2. エラー障害ヘルスチェック試行障害回復を確認できた場合サーキットブレーカー (Envoy) 1. リクエスト 2. リクエスト 4. レスポンス 3. レスポンス

37 まとめ

38 まとめマイクロサービスは複雑なシステム開発運用に効果的マイクロサービス開発運用にあたってはサービス設計に加え, サービスメッシュの最適化が求められる Istio は, サービスメッシュ最適化のソリューション

39 ワークショップセッションおよび資料は IBM またはセッション発表者によって準備されそれぞれ独自の見解を反映したものですそれらは情報提供の目的のみで提供されておりいかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなくまたそのような結果を生むものでもありません本講演資料に含まれている情報については完全性と正確性を期するよう努力しましたが現状のまま提供され明示または暗示にかかわらずいかなる保証も伴わないものとします本講演資料またはその他の資料の使用によってあるいはその他の関連によっていかなる損害が生じた場合も IBM は責任を負わないものとします本講演資料に含まれている内容は IBM またはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも IBM ソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなくまたそのような結果を生むものでもありません本講演資料で IBM 製品プログラムまたはサービスに言及していても IBM が営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません本講演資料で言及している製品リリース日付や製品機能は市場機会またはその他の要因に基づいて IBM 独自の決定権をもっていつでも変更できるものとしいかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません本講演資料に含まれている内容は参加者が開始する活動によって特定の販売売上高の向上またはその他の結果が生じると述べるまたは暗示することを意図したものでもまたそのような結果を生むものでもありませんパフォーマンスは管理された環境において標準的な IBM ベンチマークを使用した測定と予測に基づいていますユーザーが経験する実際のスループットやパフォーマンスはユーザーのジョブストリームにおけるマルチプログラミングの量入出力構成ストレージ構成および処理されるワークロードなどの考慮事項を含む数多くの要因に応じて変化しますしたがって個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません記述されているすべてのお客様事例はそれらのお客様がどのように IBM 製品を使用したかまたそれらのお客様が達成した結果の実例として示されたものです実際の環境コストおよびパフォーマンス特性はお客様ごとに異なる場合があります IBM IBM ロゴ ibm.com IBM Cloud は世界の多くの国で登録された International Business Machines Corporation の商標です他の製品名およびサービス名等はそれぞれ IBM または各社の商標である場合があります現時点での IBM の商標リストについてはをご覧ください

IBM Presentations: Smart Planet Template

IBM Presentations: Smart Planet Template Nutanix Tips 冗長性設計のヒント 2018 年 12 月 7 日日本アイビーエム株式会社システムズハードウェア事業本部 Power Systems テクニカルセールス 1 Nutanix システムの冗長性の設計耐障害性に関して以下の 2 点を決定します Redundancy Factor ノードが何台ダウンしてもクラスターが稼動し続けるか? Replication Factor