Architectures
APIMのDEV/STG/PRD環境におけるデプロイメント
このアーキテクチャでは、APIMプラットフォームがKubernetesクラスターにデプロイされ、名前空間と役割によってセグメント化されています。このシステムは、開発、ステージング、プロダクションなどの複数の環境で独立して動作するように設計されています。
Ingressレイヤーと外部/内部ルーティング
最上層では、システムは2つのロードバランサー(LB)を利用しています:
内部LB(管理者アクセス) - アクセスを提供します:
- APIMコンソール (apim-admin.company.com)
- IAMコンソール (tenant-admin.company.com)
- 管理者用開発者ポータル (developers-admin.company.com)
- 認証コンソール (auth-admin.company.com)
インターネット向けLB(ユーザーアクセス) - 外部アクセスを提供します:
- オープンAPIサービス (api.company.com)
- 公開開発者ポータル (developers.company.com)
トラフィックは、中央集権的なIngressコントローラーを通じてルーティングされ、TLS終端処理が行われ、ドメインパスに基づいてHTTPで内部サービスに転送されます。
ノードグループ: 管理
このグループは、テナント、プロジェクト、ゲートウェイ、API、およびポリシーを管理するために必要なすべてのコアコンポーネントをホストします。
主要な名前空間:
namespace: apim
コアコンポーネント:
コンポーネント | 説明 |
---|---|
テナントマネージャー (IAM) | システムユーザーとテナント組織のためのアイデンティティとアクセス管理を担当 |
テナントマネージャーコンソール | テナント管理者用のUIフロントエンド(Vue.jsで構築) |
API管理コンソールBFF | UIとサービスの相互作用を調整するバックエンドフォーフロントエンド(Vue.js & Node.js) |
ゲートウェイマネージャー | ゲートウェイのプロビジョニングとプロジェクトとの関連付けを制御 |
ポリシーマネージャー | IPフィルタリング、認証、ロギングなどのインバウンド/アウトバウンドポリシー定義を管理 |
開発者ポータル(フロントエンド&バックエンド) | APIユーザーが公開APIをブラウズし、テストするためのインターフェース |
分析マネージャー | リアルタイムAPI使用分析とレポートを処理(FluentBitと接続) |
永続データベース:
- テナントマネージャーデータベース (PostgreSQL)
- APIMデータベース マスター/スレーブ (MariaDB)
- データの耐久性と冗長性のために構成されたPVC。
ノードグループ: ユーザーノードグループ
このグループは、ランタイムAPIトラフィックを実行し、ユーザーAPI呼び出しをバックエンドマイクロサービスにルーティングします。
名前空間:
namespace: user-namespace
コンポーネント:
コンポーネント | 説明 |
---|---|
APIゲートウェイ | 入力APIリクエストを処理するKongベースのゲートウェイ |
APIゲートウェイDB | ランタイムゲートウェイ構成と状態のためのPostgreSQLストア |
インメモリDB(マスター/スレーブ) | トークン/セッションストレージに使用(おそらくRedisまたは類似) |
マイクロサービス | ルーティングされたAPIトラフィックを受け取る実際のバックエンドサービス |
APIゲートウェイは外部ユーザーからのリクエストを受け取り、以下を実行します:
- ポリシー実行(認証、IPフィルタリングなど)
- 適切なマイクロサービスへのルーティング
- 入力を介して応答を返す
ノードグループ: モニタリング
コンポーネント | 説明 |
---|---|
ロギングシステム | Elasticsearchによって提供され、構造化されたAPIログを収集するために使用 |
モニタリングシステム | Prometheusによって提供され、システムの健康状態とアラートのためのメトリクスを収集 |
ロギングおよびモニタリングコンポーネントはFluentBitおよびAPIゲートウェイログと統合され、以下を可能にします:
- リアルタイムAPIトラフィックの洞察
- カスタムメトリクスの視覚化
- Slack/Emailチャネルを介したアラート
システム通信フロー
- 管理者はIngressコントローラーを介して内部ドメイン経由でシステムにアクセスします。
- ユーザーは外部ドメイン経由でオープンAPIおよび開発者ポータルを呼び出し、Kongゲートウェイにルーティングされます。
- KongはAPIポリシー(インバウンド/アウトバウンド)を強制し、各マイクロサービスにルーティングします。
- すべてのコンポーネントからのログとメトリクスは、モニタリングおよびロギングスタックにストリーミングされます。
クラウドおよびサードパーティサービスとの統合APIMデプロイメント
このアーキテクチャは、APIMシステムがAWSなどの外部インフラストラクチャおよびCloudWatch、Datadog、Firehoseなどのロギング/モニタリングサービスとどのように統合されるかを示しています。
How It Works:- 外部ユーザーは、AWS API Gatewayを介してVPCリンクを通じて内部APIMゲートウェイにルーティングされる公開ドメインを介してシステムにアクセスします。
- プライベートドメインとRoute53は、APIMサービスが存在するKubernetesクラスターにリクエストを内部的にルーティングするために使用されます。
- リクエストがKongゲートウェイに到達すると、インバウンドポリシーが強制され(認証、ヘッダー注入など)、その後トラフィックがバックエンドサービスにルーティングされます。
- 応答はアウトバウンドポリシー(例:データマスキング、ロギング)を通過し、クライアントに返されます。
- すべてのリクエスト/応答ログとメトリクスは、統合されたエクスポーターを介してCloudWatch、Datadog、またはFirehoseに転送されます。
- Swaggerベースの仕様登録が使用され、Dev Portalを通じてAPIを動的に公開または更新します。
このアーキテクチャは、組織の境界を越えた安全でスケーラブル、かつ観測可能なAPI管理をサポートします。APIガバナンスを確保しつつ、クラウドネイティブサービスへのシームレスな拡張を可能にします。
開発環境の内部デプロイメント
このバージョンは、開発用のAPIMプラットフォームの内部専用セットアップを反映しています。APIテストやサービス開発中のセキュリティと閉じたアクセスを強調しています。
How It Works:- すべてのトラフィックは内部で流れ、プライベートDNSとALBを介してクラスターに入ります。
- 内部開発者は、事前定義された内部サブドメインを介してAPIMコンソール、開発者ポータル、およびIAMにアクセスします。
- 開発フロントエンドアプリケーションからのAPIトラフィックはKongゲートウェイに送信され、すべての構成されたポリシーが適用されます。
- バックエンドマイクロサービス(bo名前空間にホストされている)は、ゲートウェイを介してルーティングされたリクエストに応答します。
- 全体のスタックは、保守性と役割の分離のために名前空間によって分離されています:
- apimは構成と制御ロジックを含みます。
- microservicesはランタイムサービスとビジネスロジックを含みます。
このアーキテクチャは、公共ネットワークへの露出なしに安全なAPI開発とテストを可能にします。サービスの検証、ポリシーの適用、およびステージングまたはプロダクション展開前のアクセス制御の確認に最適です。
開発専用内部フローモデル
このアーキテクチャは、開発環境内の詳細な内部トラフィックフローを示し、ネットワークの境界と隔離に焦点を当てています。
How It Works:- 内部アプリケーションと開発者は、プライベートドメインとNLB/ALBルーティングを介してAPIMコンソールまたは開発者ポータルと対話します。
- フロントエンドからのリクエストはKongゲートウェイにルーティングされ、認証、レート制限、変換などのランタイムポリシーが強制されます。
- ゲートウェイは、同じクラスターにホストされているバックエンドマイクロサービスまたはサービスメッシュ(該当する場合)にリクエストをルーティングします。
- API使用状況、ログ、およびトラフィック統計は、Datadogなどの内部可視化ツールに送信され、開発操作中の可視性を確保します。
- この環境には公開向けのアクセスポイントはなく、APIゲートウェイを含むすべてのコンポーネントは厳密に内部です。
このセットアップは、APIの開発とテストのための安全で隔離されたパイプラインを確保し、完全なモニタリングとガバナンス機能を保持します。開発チームは、外部露出なしに本番に近いAPIの動作をシミュレートできます。
コンポーネントの説明とリソース
この表は、APIMコントロールプレーン内の各コンポーネントに割り当てられたCPU、メモリ、およびストレージリソースを概説しています。これは、インフラストラクチャおよびDevOpsチームがKubernetesクラスターを正確かつ効率的に計画し、プロビジョニングするのに役立ちます。
Instance | Description | kind | Replicas | CPU (m) | CPU Total (m) | Memory (Mi) | Memory Total (Mi) | Storage (GB) | Storage Total (GB) |
---|---|---|---|---|---|---|---|---|---|
deploy-apim-analysis-manager | 分析マネージャー | デプロイメント | 1 | 0.5 | 0.5 | 1024 | 1024 | 0 | 0 |
deploy-apim-bff | APIMコンソールBFF | デプロイメント | 1 | 0.5 | 0.5 | 512 | 512 | 0 | 0 |
deploy-apim-gateway-manager | ゲートウェイマネージャー | デプロイメント | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
deploy-apim-tenant-manager | テナントマネージャー (IAM) | デプロイメント | 1 | 0.5 | 0.5 | 768 | 768 | 0 | 0 |
deploy-apim-tenant-manager-console | テナントマネージャーコンソール | デプロイメント | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
deploy-apim-policy-manager | ポリシーマネージャー | デプロイメント | 1 | 0.2 | 0.2 | 512 | 512 | 0 | 0 |
deploy-apim-developer-portal-backend | デベロッパーポータルバックエンド | デプロイメント | 1 | 0.2 | 0.2 | 512 | 512 | 20 | 20 |
deploy-apim-developer-portal-frontend | デベロッパーポータルフロントエンド | デプロイメント | 1 | 0.2 | 0.2 | 64 | 64 | 0 | 0 |
deploy-apim-mariadb-master | APIM DB (MariaDBマスター) | ステートフルセット | 1 | 0.5 | 0.5 | 512 | 512 | 10 | 10 |
deploy-apim-mariadb-slave | APIM DB (MariaDBスレーブ) | ステートフルセット | 1 | 0.2 | 0.2 | 256 | 256 | 0 | 0 |
statefulset-apim-tenant-manager-postgresql | IAM DB (PostgreSQL) | ステートフルセット | 1 | 0.5 | 0.5 | 256 | 256 | 10 | 10 |
合計 | 4 | 5760 | 40 |
- CPU: 4コア
- メモリ: 6 GiB
- ストレージ: 40 GB
Notes:
- CPU/メモリはレプリカスケーリングポリシーに応じて増加します
- ロギング/モニタリングストレージはトラフィック量に応じてスケールします
- 1つのパブリックAPIMデプロイメントと1つのプライベートAPIMデプロイメントがサポートされています