クラスタ
Chip-in はマイクロサービスアーキテクチャを採用しており、複数のサービスを収容するためのクラスタを構成します。 クラスタ内には複数のサービスを収容することができます。クラスタはサービス間通信のためのプライベートなネットワークとインターネットとのゲートウェイを持ちます。
クラスタにコアサービスが含まれている場合は、ゲートウェイはグローバルIPを持ち、インターネットからの通信を受けつけ、HTTPS, QUIC の接続をコアサービスに DNAT します。
コアサービスが含まれていない場合は、ゲートウェイはコアサービスへの接続のみを提供します。 クラスタは IaaS 上に構築するのが一般的ですが、オンプレミス上のデバイスにアクセスする場合や開発環境などでは、単一サーバ上の docker compose であったり、 kubernaetes, docker swarm などのコンテナクラスタであったりします。
サービスとインスタンス
コアサービスもマイクロサービスもサービスの一種です。サービスにはインスタンスの定義が登録されており、デプロイするとインスタンスが起動されます。冗長負荷分散の目的で、一つのサービスに同じインスタンスを複数起動することもできます。これをレプリカセットと呼びます。
コンテナ
一つのインスタンスの中に複数のコンテナを収容できます。その場合、メインとなるコンテナに対して補助的な機能を提供するコンテナをサイドカーと呼びます。 一つのインスタンスの中でコンテナ間通信する場合、127.0.0.* のアドレスで通信できます。この場合、通信はインスタンス内で閉じており、物理的にも一つのホストサーバの中で通信することが保証されます。逆にサイドカーをメインとなるコンテナと別のホストサーバに分散して動作させることはできません。
IaaS 上の用語
クラウドベンダごとの用語と Chip-in で使用する用語の対応は以下のとおりです。
| Chip-in | AWS ECS | GCP Cloud Run | Azure Container Apps |
|---|---|---|---|
| クラスタ | ECS クラスタ | (GCPプロジェクト / リージョン) | 環境 (Environment) |
| サービス | ECS サービス | Cloud Run サービス | コンテナアプリ (Container App) |
| インスタンス | ECS タスク | Cloud Run インスタンス | Pod / レプリカ |
| コンテナ | ECS コンテナ | コンテナ | コンテナ |
Chip-in の階層構造は docker compose, kubernaetes, docker swarm の個々の概念モデルに直接写像できません。個々の実装で同様の概念モデルを構成する必要があります。以下の課題が判明しています。
- docker compose はレプリカセットをサポートしていません。
- docker swarm はサイドカーをサポートしていません。
- kubernetes は機能的にすべてをサポートしていますが自由度が高すぎるため、IaCの書き方で Chip-in の階層構造を実装する必要があります。