microservices-patterns

Name: microservices-patterns
Author: manutej

github.com/manutejクラウド・DevOps62447 回インストール40 週間前に更新

リポジトリ

microservices-patterns について

分散システムの設計者や運用チーム向けのスキルです。Istio と Kubernetes によるサービスメッシュ、トラフィック管理、耐障害性、セキュリティ、可観測性を扱います。

主な機能

01サービスメッシュと Istio の構成
02トラフィックルーティング、分割、負荷分散
03リトライ、タイムアウト、サーキットブレーカー
04mTLS と認可ポリシー
05分散トレーシングと可観測性

活用シーン

01カナリアまたはブルーグリーンデプロイの設定
02サービス障害の分離とリトライポリシーの設定
03サービス間通信の保護
04マイクロサービスのリクエスト経路の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/manutej/luxor-claude-marketplace --skill microservices-patterns

インストール後、Claude Code で/microservices-patternsを入力して読み込まれたか確認します。

同梱ファイルEXAMPLES.mdREADME.md

詳細

マイクロサービスのパターン

本番環境に対応したマイクロサービスアーキテクチャを構築、デプロイ、管理するための包括的なスキルです。Istio と Kubernetes を使用したサービスメッシュのパターン、トラフィック管理、レジリエンスエンジニアリング、可観測性、セキュリティ、最新のマイクロサービスのベストプラクティスを取り上げます。

このスキルを使用する場面

次のような場合に、このスキルを使用してください。

分散システムを用いたマイクロサービスベースのアプリケーションを設計する
サービス間通信のためのサービスメッシュ基盤を実装する
サーキットブレーカー、リトライ、タイムアウトなどのレジリエンスパターンを追加する
トラフィックルーティング、ロードバランシング、カナリアデプロイを管理する
マイクロサービス全体に分散トレーシングと可観測性を実装する
mTLS と認可ポリシーでマイクロサービスを保護する
障害の連鎖やサービスの劣化をトラブルシューティングする
フォールトトレラントな分散システムを構築する
ブルーグリーンデプロイと A/B テストを実装する
マルチクラスターのマイクロサービスデプロイを管理する
カオスエンジニアリングと障害注入を実装する
モノリシックアーキテクチャからマイクロサービスアーキテクチャに移行する

コアコンセプト

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャでは、アプリケーションを疎結合なサービスの集合として構成します。

サービスの独立性：各サービスは個別にデプロイおよびスケーリングできます
ドメイン駆動設計：サービスはビジネスの機能に沿って構成されます
分散データ：各サービスは独自のデータストアを所有します
API ファースト：サービスは明確に定義された API を介して通信します
ポリグロット永続化：サービスごとに異なるデータベースを使用できます
障害分離：サービスの障害がシステム全体に連鎖しません

サービスメッシュの基礎

サービスメッシュは、サービス間通信を処理するためのインフラストラクチャ層です。

データプレーン：各サービスの横にデプロイされるサイドカープロキシ（Envoy）
コントロールプレーン：プロキシを管理および構成します（Istio、Linkerd、Consul）
サービスディスカバリー：サービスを自動的に登録し、検出します
ロードバランシング：サービスインスタンス間でトラフィックをインテリジェントに分散します
可観測性：メトリクス、ログ、分散トレーシングが組み込まれています
セキュリティ：mTLS、認証、認可

Istio アーキテクチャ

Istio は最も広く使われているサービスメッシュの実装です。

コントロールプレーンのコンポーネント：

Istiod：サービスディスカバリー、構成、証明書管理を統合したコントロールプレーン
Pilot：トラフィック管理とサービスディスカバリー
Citadel：mTLS 用の認証局
Galley：構成の検証と配布

データプレーン：

Envoy Proxy：各サービス用の高性能サイドカープロキシ
Iptables Rules：トラフィックの透過的なインターセプト
Service Proxy：サービスのすべてのネットワークトラフィックを処理します

主なサービスメッシュパターン

サイドカーパターン：アプリケーションコンテナの横にプロキシをデプロイします
サービスディスカバリー：サービスを自動的に登録し、検出します
トラフィック分割：トラフィックの一部を異なるバージョンにルーティングします
サーキットブレーカー：障害の連鎖を防ぎます
リトライロジック：指数バックオフを用いて自動的に再試行します
タイムアウトポリシー：リクエストのタイムアウトを構成します
障害注入：本番環境でカオステストを実施します
レート制限：過負荷からサービスを保護します
mTLS：サービス間通信を暗号化する相互 TLS
分散トレーシング：サービス間のリクエストフローを追跡します

トラフィック管理

仮想サービス

仮想サービスは、メッシュ内のトラフィックに対するルーティングルールを定義します。

主な機能：

HTTP/TCP/TLS ルーティング：プロトコルに応じたルーティングルール
一致条件：ヘッダー、URI、メソッドに基づいてルーティングします
重み付きルーティング：バージョン間でトラフィックを分割します
リダイレクトと書き換え：URL を操作します
障害注入：遅延と中断を注入します
リトライ：自動リトライを構成します
タイムアウト：リクエストのタイムアウトポリシー

仮想サービスの構造：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

宛先ルール

宛先ルールでは、ルーティング後のトラフィックに適用するポリシーを設定します。

主な機能：

ロードバランシング：ラウンドロビン、ランダム、最少リクエスト
コネクションプール：接続数の上限とタイムアウト
異常検出：サーキットブレーカーの設定
TLS 設定：mTLS モードの設定
サブセット定義：バージョンベースのサービスサブセット

一般的なロードバランシング戦略：

ROUND_ROBIN：デフォルト。均等に分散します
LEAST_REQUEST：リクエスト数が最も少ないインスタンスにルーティングします
RANDOM：ランダムに分散します
PASSTHROUGH：元の宛先を使用します

トラフィック分割

トラフィック分割により、段階的なロールアウトや A/B テストが可能になります。

ユースケース：

カナリアデプロイ：新しいバージョンに少量のトラフィックをルーティングします
ブルーグリーンデプロイ：バージョン間でトラフィックを切り替えます
A/B テスト：実験のためにトラフィックを分割します
ダークローンチ：新しいバージョンにシャドートラフィックを送ります

プログレッシブデリバリーパターン：

v1: 100% → 90% → 70% → 50% → 20% → 0%
v2:   0% → 10% → 30% → 50% → 80% → 100%

ゲートウェイ設定

ゲートウェイは、イングレスおよびエグレストラフィックを管理します。

イングレスゲートウェイ：

外部トラフィックの入口
TLS 終端
プロトコル固有のルーティング
仮想ホスティング

エグレスゲートウェイ：

アウトバウンドトラフィックの制御
外部サービス向けセキュリティポリシー
トラフィックの監視とログ記録

レジリエンスパターン

サーキットブレーカーパターン

サーキットブレーカーは、障害が発生しているサービスを検出して隔離することで、障害の連鎖を防ぎます。

状態：

閉：正常に動作し、リクエストが通過します
開：サービスに障害が発生しており、リクエストは即座に失敗します
半開：サービスが復旧したかどうかをテストします

設定パラメーター：

連続エラー数：サーキットを開くまでのエラー数
間隔：エラーをカウントする時間枠
基本排除時間：障害のあるインスタンスを排除する時間
最大排除率：プールから排除する最大割合

利点：

リソースの枯渇を防ぎます
タイムアウトまで待たずにすばやく失敗します
障害のあるサービスに復旧の時間を与えます
サービスの健全性を自動的に監視します

リトライロジック

インテリジェントなバックオフ戦略による自動リトライです。

リトライ戦略：

固定遅延：リトライ間の遅延を一定にします
指数バックオフ：リトライ間の遅延を段階的に増やします
ジッター付きバックオフ：ランダムなジッターを加えて、サンダリングハードを防ぎます

設定：

試行回数：リトライの最大回数
試行ごとのタイムアウト：各試行のタイムアウト
リトライ条件：リトライを開始する条件（5xx、タイムアウト、refused-stream）
バックオフ：基本間隔と最大間隔

ベストプラクティス：

冪等な操作のみをリトライします
ジッター付き指数バックオフを使用します
リトライの最大回数を設定します
リトライ率を監視します

タイムアウトポリシー

タイムアウトポリシーは、無期限の待機を防ぎます。

タイムアウトの種類：

リクエストタイムアウト：リクエスト全体のタイムアウト
試行ごとのタイムアウト：リトライ試行ごとのタイムアウト
アイドルタイムアウト：接続のアイドルタイムアウト
接続タイムアウト：初期接続のタイムアウト

タイムアウトの階層：

Overall Request Timeout
├─ Retry 1 (Per Try Timeout)
├─ Retry 2 (Per Try Timeout)
└─ Retry 3 (Per Try Timeout)

ベストプラクティス：

SLA 要件に基づいてタイムアウトを設定します
重要な経路には短いタイムアウトを使用します
試行ごとのタイムアウトは全体のタイムアウトより短く設定します
タイムアウト率を監視し、調整します

バルクヘッドパターン

バルクヘッドはリソースを隔離し、システム全体の障害を防ぎます。

実装：

スレッドプール：サービスごとに個別のスレッドプールを使用します
コネクションプール：アップストリームごとに接続数を制限します
キューの上限：メモリーの問題を防ぐため、キューのサイズに上限を設けます
セマフォ：同時リクエスト数を制限します

設定：

最大接続数：同時接続数の上限
接続あたりの最大リクエスト数：HTTP/2 の同時リクエスト数
保留中の最大リクエスト数：保留中リクエストのキューサイズ
接続タイムアウト：接続の確立にかける時間

レート制限

レート制限は、サービスの過負荷を防ぎます。

レート制限の種類：

グローバルレート制限：すべてのインスタンスを対象とします
ローカルレート制限：インスタンスごとに適用します
ユーザーベース：ユーザーまたは API キーごとに適用します
エンドポイントベース：API エンドポイントごとに適用します

アルゴリズム：

トークンバケット：平均レートを維持しながら、一時的なバーストを許容します
リーキーバケット：トラフィックの急増を平滑化します
固定ウィンドウ：時間枠に基づくシンプルな制限方式です
スライディングウィンドウ：固定ウィンドウよりも正確です

負荷分散

サービスレベルの負荷分散

Istio はインテリジェントなレイヤー 7 負荷分散を提供します。

負荷分散アルゴリズム：

ラウンドロビン
- デフォルトのアルゴリズムです
- インスタンス間で均等に分散します
- シンプルで予測可能です
- 同種のインスタンスに適しています
最小リクエスト数
- アクティブなリクエスト数が最も少ないインスタンスにルーティングします
- 異種のインスタンスにより適しています
- 応答時間の変動に適応します
- リクエスト追跡のオーバーヘッドが発生します
ランダム
- インスタンスをランダムに選択します
- 状態を必要としません
- 大規模なプールに適しています
- 時間の経過とともに統計的に分散されます
コンシステントハッシュ
- ハッシュベースのルーティング（スティッキーセッション）です
- 同じクライアント → 同じバックエンドにルーティングします
- キャッシュを利用するシナリオに適しています
- ヘッダー、Cookie、または送信元 IP を使用します

コネクションプール管理

コネクションプールはリソースの使用量を制御します。

TCP 設定：

最大接続数：アップストリームへの合計接続数です
接続タイムアウト：接続確立時のタイムアウトです
TCP キープアライブ：キープアライブプローブの設定です

HTTP 設定：

HTTP1 最大保留リクエスト数：キューのサイズです
HTTP2 最大リクエスト数：同時ストリーム数です
接続あたりの最大リクエスト数：接続再利用の上限です
最大再試行回数：未完了の再試行の上限です

ヘルスチェック

アクティブおよびパッシブのヘルスチェック：

パッシブヘルスチェック（外れ値検出）：

実際のトラフィックを監視します
追加のプローブによるオーバーヘッドがありません
障害を自動的に検出します
異常なインスタンスを除外します

アクティブヘルスチェック：

明示的なヘルスプローブリクエストを送信します
トラフィックに依存しません
間隔を設定できます
カスタムのヘルスエンドポイントを使用できます

セキュリティ

相互 TLS（mTLS）

mTLS は、サービス間通信の暗号化と認証を提供します。

mTLS の利点：

暗号化：転送中のすべてのトラフィックを暗号化します
認証：サービス同士が相互に認証します
認可：ポリシー適用のためのサービス ID を提供します
証明書のローテーション：証明書を自動的に管理します

mTLS モード：

STRICT：すべてのトラフィックで mTLS を必須にします
PERMISSIVE：mTLS と平文の両方を受け入れます（移行モード）
DISABLE：mTLS を適用しません

証明書管理：

Citadel による証明書の自動発行
有効期間の短い証明書（デフォルトは 24 時間）
自動ローテーション
SPIFFE 準拠の ID

認可ポリシー

サービス間のきめ細かなアクセス制御：

ポリシーの種類：

ALLOW：トラフィックを明示的に許可します
DENY：トラフィックを明示的に拒否します
CUSTOM：カスタムの認可ロジックを使用します

一致条件：

ソース：ソースサービスの ID、名前空間、IP
宛先：対象サービス、ポート、パス
リクエスト：HTTP メソッド、ヘッダー、パラメーター
JWT クレーム：トークンベースの認可

ポリシー階層：

Namespace-level default → Service-level → Specific paths

認証ポリシー

認証要件を設定します。

ピア認証：

サービス間認証
mTLS モードの設定
ポートごとの設定

リクエスト認証：

エンドユーザー認証
JWT 検証
カスタム認証プロバイダー
トークン転送

可観測性

分散トレーシング

マイクロサービス間のリクエストを追跡します。

主な概念：

トレース：リクエストの全行程
スパン：個々のサービス操作
親子関係：サービス呼び出しの階層
トレースコンテキスト：伝播されるメタデータ

トレーシングバックエンド：

Jaeger：CNCF の分散トレーシング
Zipkin：Twitter の分散トレーシング
Tempo：Grafana のトレーシングバックエンド
AWS X-Ray：AWS の分散トレーシング

トレースのサンプリング：

常時サンプリング：サンプリング率 100％（開発時）
確率的サンプリング：指定した割合でサンプリング（例：1％）
レート制限：1 秒あたりの最大トレース数
適応型サンプリング：トラフィックに基づく動的なサンプリング

メトリクスの収集

Istio は豊富なメトリクスを自動的に提供します。

サービスメトリクス：

リクエストレート：1 秒あたりのリクエスト数
エラーレート：失敗したリクエストの割合
所要時間：リクエストのレイテンシ（p50、p95、p99）
リクエストサイズ：リクエスト／レスポンスのペイロードサイズ

インフラストラクチャメトリクス：

CPU／メモリ：リソース使用率
コネクションプール：プールの統計情報
サーキットブレーカー：サーキットの状態とイベント
リトライ／タイムアウト：リトライ率とタイムアウト率

ゴールデンシグナル：

レイテンシ：リクエストにかかる時間
トラフィック：リクエストレート
エラー：エラーレート
飽和度：リソース使用率

ロギング

マイクロサービス向けの構造化ロギングです。

ログの種類：

アクセスログ：リクエスト／レスポンスのロギング
アプリケーションログ：サービス固有のログ
プロキシログ：Envoy サイドカーのログ
コントロールプレーンログ：Istio コンポーネントのログ

アクセスログの形式：

{
  "timestamp": "2025-10-18T10:30:00Z",
  "method": "GET",
  "path": "/api/users",
  "status": 200,
  "duration_ms": 45,
  "upstream_service": "user-service-v2",
  "trace_id": "abc123",
  "user_agent": "mobile-app/2.1"
}

Kiali による可視化

Kiali はサービスメッシュの可観測性を提供します。

機能：

サービスグラフ：サービスのトポロジーを視覚的に表示
トラフィックフロー：リクエストフローを可視化
ヘルスステータス：サービスの健全性を示す指標
設定の検証：Istio 設定の検証
分散トレーシング：Jaeger トレースとの統合

ベストプラクティス

サービス設計

単一責任：各サービスは一つのことに集中します
API ファースト設計：実装前に API を定義します
冪等性：安全性を確保するため、冪等な操作を設計します
バージョニング：複数の API バージョンをサポートします
後方互換性：既存のクライアントを壊さないようにします

デプロイ戦略

ブルーグリーンデプロイ
- 同一の環境を二つ維持します
- トラフィックをアトミックに切り替えます
- ロールバックが容易です
- リソースコストが高くなります
カナリアデプロイ
- ユーザーの一部に段階的に展開します
- 全面展開の前にメトリクスを監視します
- 一斉展開よりリスクが低くなります
- オーケストレーションがより複雑になります
ローリングアップデート
- インスタンスを段階的に置き換えます
- 追加のリソースは不要です
- Kubernetes のネイティブサポートがあります
- 一時的に複数のバージョンが共存します
ダークローンチ
- シャドウトラフィックを新しいバージョンにルーティングします
- 本番トラフィックでテストします
- ユーザーへの影響はありません
- 実際のトラフィックを流す前に検証します

レジリエンスエンジニアリング

障害を前提に設計する：サービスは障害を起こすものと想定します
速やかに失敗させる：タイムアウトまで待ちません
段階的縮退：機能が一部でも使えるほうが、まったく使えないより優れています
冪等なリトライ：操作を安全に再試行できるようにします
バルクヘッドによる分離：障害の影響範囲を分離します
サーキットブレーカー：障害の連鎖を防ぎます
あらゆる箇所にタイムアウトを設定する：無期限に待機しないようにします
カオスエンジニアリング：障害シナリオをテストします

設定管理

名前空間の分離：環境（dev、staging、prod）を分離します
GitOps：設定を Git に保存します
検証：適用前に設定を検証します
段階的な展開：まず開発環境で設定をテストします
バージョン管理：すべての設定変更を追跡します
ドキュメント化：設定に関する判断を文書化します

セキュリティのベストプラクティス

デフォルトでの mTLS：サービスのトラフィックは常に暗号化します
最小権限：認可ポリシーを最小限にします
ネットワークのセグメンテーション：名前空間ごとにサービスを分離します
シークレット管理：シークレットをハードコードしません
定期的なアップデート：Istio と Envoy を最新の状態に保ちます
監査ログ：すべての認可判断を記録します

モニタリングとアラート

SLI/SLO/SLA：サービスレベル目標を定義します
ダッシュボードの設計：実行可能なメトリクスに重点を置きます
アラート疲れ：対応可能な項目に対してのみアラートを出します
エラーバジェット：信頼性と開発速度のバランスを取ります
ランブック：インシデント対応を文書化します
ポストモーテム：障害から学びます

パフォーマンスの最適化

コネクションプーリング：接続を再利用します
リクエストのバッチ処理：可能な場合はバッチ処理します
キャッシュ：複数のレベルでキャッシュします
圧縮：レスポンスの圧縮を有効にします
プロトコルの選択：効率化のために HTTP/2 または gRPC を使用します
リソース制限：適切な制限を設定します
水平スケーリング：垂直方向ではなく、水平方向にスケールアウトします

移行戦略

モノリスの移行にはストラングラーパターンを使用します：

Phase 1: Route some traffic to microservices
Monolith (90%) + Microservices (10%)

Phase 2: Gradually increase microservice traffic
Monolith (70%) + Microservices (30%)

Phase 3: Continue migration
Monolith (40%) + Microservices (60%)

Phase 4: Complete migration
Monolith (0%) + Microservices (100%)

よくあるパターン

パターン 1：API ゲートウェイパターン

すべてのクライアントリクエストに対する単一のエントリポイント：

コンポーネント：

外部ゲートウェイ（Istio Ingress）
ルーティング用の仮想サービス
レート制限と認証
TLS 終端

利点：

クライアントインターフェースの簡素化
認証の一元化
プロトコル変換
リクエストの集約

パターン 2：Backend for Frontend（BFF）

フロントエンドの種類ごとに専用のバックエンドを用意します：

ユースケース：

モバイルアプリとウェブアプリでは必要なものが異なる
クライアントごとに異なるデータ集約
クライアント固有の最適化
過剰なデータ取得の削減

実装：

クライアントの種類ごとに個別の BFF サービスを用意します
user-agent またはサブドメインでルーティングします
クライアントごとにレスポンスを最適化します
個別にスケーリングします

パターン 3：Saga パターン

分散トランザクションの管理：

コレオグラフィーベース：

サービスがイベントを発行します
他のサービスがイベントに反応します
中央のコーディネーターはありません
疎結合です

オーケストレーションベース：

中央のオーケストレーター
明示的なトランザクションフロー
理解しやすい構成
単一の調整ポイント

パターン 4：CQRS（コマンドクエリ責務分離）

読み取りモデルと書き込みモデルを分離します：

利点：

読み取りパスと書き込みパスの最適化
個別のスケーリング
異なるデータモデル
イベントソーシングとの互換性

実装：

書き込みサービスがデータを更新します
読み取りサービスが最適化されたビューをクエリします
同期用のイベントバス
結果整合性のある読み取り

パターン 5：サービスレジストリパターン

動的なサービスディスカバリー：

コンポーネント：

サービスレジストリ（Kubernetes DNS）
サービス登録（自動）
サービスディスカバリー（Istio pilot）
ヘルスチェック

利点：

動的なスケーリング
自動フェイルオーバー
エンドポイントのハードコードが不要
ロケーション透過性

パターン 6：サイドカーパターン

サービスと並行して補助機能をデプロイします：

一般的なサイドカー：

Envoy プロキシ（トラフィック管理）
ログシッパー（ログの一元管理）
メトリクスコレクター（モニタリング）
シークレットマネージャー（認証情報の注入）

利点：

関心事の分離
ポリグロット対応
一貫した機能
個別のアップデート

パターン 7：アンバサダーパターン

外部サービスへのアクセス用プロキシ：

ユースケース：

レガシーシステムとの統合
外部 API のレート制限
プロトコル変換
外部レスポンスのキャッシュ

実装：

外部呼び出し用のサイドカー
外部サービス用のサーキットブレーカー
リトライロジックとタイムアウト
モニタリングとログ記録

パターン 8：腐敗防止層

レガシーシステムの複雑さを隔離します：

目的：

ドメインモデル間の変換
新しいアーキテクチャの保護
段階的な移行のサポート
レガシーシステムの抽象化

実装：

アダプターサービス層
モデル変換
プロトコル変換
バージョニングのサポート

高度なテクニック

マルチクラスターサービスメッシュ

複数のクラスターにサービスメッシュを拡張します。

ユースケース：

マルチリージョンデプロイ
高可用性
災害復旧
コンプライアンス要件

実装：

単一のコントロールプレーンまたはマルチプライマリー
クラスター間のサービスディスカバリー
クラスター間のロードバランシング
一貫性のあるポリシー

サービスメッシュフェデレーション

複数の独立したサービスメッシュを接続します。

シナリオ：

複数のチーム／組織
合併・買収
レガシーメッシュの移行
異なるメッシュ実装

カオスエンジニアリング

システムのレジリエンスを事前にテストします。

カオス実験：

サービス障害（Pod の削除）
ネットワーク遅延の注入
エラーの注入（HTTP 503）
リソース制限（CPU／メモリ）
DNS 障害
証明書の有効期限切れ

ツール：

Istio のフォールトインジェクション
Chaos Mesh
Litmus Chaos
Gremlin

サービスメッシュの GitOps

宣言型の構成管理です。

ワークフロー：

Git で構成を変更
自動検証
レビューと承認
自動デプロイ
継続的な監視

メリット：

バージョン管理
監査証跡
災害復旧
一貫性

トラブルシューティング

よくある問題

問題 1：サービスにアクセスできない

サイドカーのインジェクションを確認します
VirtualService の構成を検証します
DestinationRule のサブセットを確認します
サービスディスカバリーを検証します
認可ポリシーを確認します

問題 2：レイテンシーが高い

再試行とタイムアウトの設定を確認します
接続プールの上限を確認します
分散トレースを分析します
リソース制限を確認します
ロードバランシングアルゴリズムを確認します

問題 3：サーキットブレーカーが機能しない

アウトライヤー検出の構成を検証します
エラーのしきい値を確認します
連続エラーの設定を確認します
基本排除時間を検証します
排除メトリクスを監視します

問題 4：mTLS の失敗

PeerAuthentication のモードを確認します
証明書の有効性を検証します
認可ポリシーを確認します
名前空間のメッシュ構成を確認します
Citadel の動作を検証します

問題 5：トラフィックのルーティングに関する問題

VirtualService のホストを検証します
サブセットの定義を確認します
マッチ条件を確認します
ゲートウェイの構成を検証します
サービスセレクターのラベルを確認します

デバッグツール

istioctl：Istio 管理用 CLI
- istioctl analyze：構成を検証します
- istioctl proxy-status：プロキシの同期状態を確認します
- istioctl proxy-config：プロキシの構成を表示します
- istioctl dashboard：ダッシュボードにアクセスします
kubectl：Kubernetes 管理
- Pod の状態を確認します
- ログを表示します
- ポートフォワーディングを行います
- リソースを調査します
Kiali：サービスメッシュの可視化
- サービスグラフ
- トラフィックフロー
- 構成の検証
- 分散トレーシング
Jaeger：分散トレーシング
- リクエストトレース
- レイテンシー分析
- サービスの依存関係
- エラーの特定
Prometheus/Grafana：メトリクスと可視化
- サービスメトリクス
- カスタムダッシュボード
- アラートルール
- 履歴分析

シナリオ例

シナリオ 1：E コマースのマイクロサービス

アーキテクチャ：

フロントエンド（React SPA）
API ゲートウェイ
Product Service
Cart Service
Order Service
Payment Service
Inventory Service
Notification Service

トラフィック管理：

新しい商品検索のカナリアデプロイ
Payment Service のサーキットブレーカー
在庫確認の再試行ロジック
外部決済 API のタイムアウトポリシー
API ゲートウェイでのレート制限

レジリエンス：

レコメンデーションに障害が発生した場合のグレースフルデグラデーション
決済処理のバルクヘッド分離
キャッシュされた商品データへのフォールバック
非同期通知用のキュー

シナリオ 2：ストリーミングプラットフォーム

アーキテクチャ：

動画サービス（トランスコーディング）
メタデータサービス（コンテンツ情報）
レコメンデーションサービス（ML ベース）
ユーザーサービス（プロフィール）
CDN 統合
アナリティクスサービス

トラフィック管理：

レコメンデーションアルゴリズムの A/B テスト
エッジサービスへの地理的ルーティング
サーバー容量に基づく負荷分散
新しい動画プレーヤーへのトラフィック分割

パフォーマンス：

レイテンシを低減する HTTP/2
データベースのコネクションプーリング
複数レベルでのキャッシュ
アダプティブビットレートストリーミング

シナリオ 3：金融サービスプラットフォーム

アーキテクチャ：

アカウントサービス
トランザクションサービス
不正検知サービス
レポートサービス
外部銀行との統合
監査サービス

セキュリティ：

すべてのサービスで厳格な mTLS を使用
きめ細かな認可ポリシー
コンプライアンスのための監査ログ
機密度に基づくネットワーク分割

レジリエンス：

外部銀行向けのサーキットブレーカー
冪等性のあるトランザクション処理
分散トランザクション向けの Saga パターン
監査証跡向けのイベントソーシング

統合パターン

サービスごとのデータベース

各マイクロサービスがそれぞれのデータベースを所有します。

メリット：

独立したスケーリング
技術選択の自由
障害の分離
明確な所有権

課題：

分散トランザクション
データの一貫性
クエリの複雑さ
データの重複

解決策：

イベント駆動アーキテクチャ
Saga パターン
CQRS
API コンポジション

イベント駆動アーキテクチャ

イベントを介した非同期通信です。

コンポーネント：

イベントプロデューサー
イベントバス（Kafka、RabbitMQ）
イベントコンシューマー
イベントストア

パターン：

イベント通知
イベントによる状態転送
イベントソーシング
CQRS

API コンポジション

複数のサービスからデータを集約します。

実装：

API ゲートウェイがサービスにクエリを送信
サービスへの並列呼び出し
レスポンスの集約
エラー処理

最適化：

キャッシュ
リクエストのバッチ処理
部分レスポンス
タイムアウト管理

リソースと参考資料

公式ドキュメント

Istio ドキュメント：https://istio.io/docs
Kubernetes ドキュメント：https://kubernetes.io/docs
Envoy Proxy：https://www.envoyproxy.io/docs
CNCF Service Mesh Landscape：https://landscape.cncf.io/card-mode?category=service-mesh

書籍と論文

Sam Newman 著『Building Microservices』
Chris Richardson 著『Microservices Patterns』
Susan Fowler 著『Production-Ready Microservices』
Martin Abbott 著『The Art of Scalability』

ツールとプラットフォーム

Istio：サービスメッシュのコントロールプレーン
Linkerd：軽量なサービスメッシュ
Consul Connect：HashiCorp のサービスメッシュ
AWS App Mesh：AWS ネイティブのサービスメッシュ
Kiali：サービスメッシュの可観測性
Jaeger：分散トレーシング
Prometheus：メトリクス収集
Grafana：可視化

コミュニティリソース

Istio ブログ：https://istio.io/blog
CNCF Slack：#istio チャンネル
Stack Overflow：[istio] タグ
GitHub：istio/istio リポジトリ

スキルバージョン：1.0.0 最終更新日：2025 年 10 月 スキルカテゴリ：マイクロサービス、サービスメッシュ、クラウドネイティブ、DevOps 対応バージョン：Istio 1.20 以降、Kubernetes 1.28 以降、Envoy Proxy 前提条件：Kubernetes の知識、コンテナ化、ネットワークの基礎

Markdown 対応

ログインしてコメント

基本情報

作者: manutej
リポジトリ: manutej/luxor-claude-marketplace
カテゴリ: クラウド・DevOps
インストール数: 447
GitHub スター: 62

問題を報告