CaaSの課題について

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤という本を読んでいる。 CaaS(Container as a Service)の章に、 3.4 CasSの提供における課題(設計/運用など) という項があったので、メモしておく。

1クラスタあたりのサイジング

  • クラスタの規模は有限なため、リソースの分配をきちんと設計する必要がある
  • コンテナを大量に収容することは可能だが、以下のような問題が発生する
    • 死活監視のためのヘルスチェック通信がネックになる
    • オーケストレータと各ノードの通信がネックになる
  • どうしても理由がない限り、マルチクラスタ/マルチクラウドを検討する
    • スケーラビリティを損なわないまま、障害が他のクラスタに波及することを防げるかもしれない

ヘルスチェック

  • 一般的には以下のような監視サービスが提供されている
    • TCP/UDPのポートの疎通
    • HTTP(S)ポートからの応答
    • コマンド実行結果
  • 実装パターンには以下のようなものがある

    • オーケストレータがコンテナに個別にヘルスチェックを実行する
    • ノード内のエージェントがヘルスチェックを行う
  • オーケストレータがヘルスチェックを行う場合、コンテナとオーケストレータの通信がボトルネックになることがある

  • エージェントがヘルスチェックを行う場合、エージェントが結果をサマライズしてオーケストレータに送信するまでにラグが発生することがある

  • 上記を検討する必要がある

サービスディスカバリ

  • Caas上で起動するコンテナは、動的に収容されるノードが変わる
  • コンテナの再起動時に、IPアドレスにやポートマッピングは変更される
  • サービスディスカバリとはコンテナのステートを監視し、収集した情報をKVSに格納、問い合わせがあった際はそれらを返すサービスである
    • 返すプロトコルにはDNS/HTTPなどが考えられる
  • DNSは実績十分だが、ポートの識別や、キャッシュ機構(キャッシュできないケースも有る)など、実用性は低い
  • また、コンテナのスケールアウト時にボトルネックになる可能性がある
    • その結果、更新漏れ等が発生する可能性もある
  • よって、適切なサービスディスカバリ方法を検討する必要がある

インスタンスのコネクションの上限

  • 仮想インスタンスは、1台の物理サーバ上にハイパーバイザー型のVMとして起動している
  • 仮想スイッチ技術を使用して仮想ネットワークがクマれているため、通信のオーバーヘッドが発生しやすい
  • その結果、コネクション数に制限が設けられていることがある
  • 制限に到達すると、遅延等が発生する可能性がある
  • CaaSクラスタを載せている仮想インスタンスに上記のような事象が発生する以下のようなことが発生する可能性がある
    • ヘルスチェックに応答を返せず、延々オンテナが再起動を繰り返す
    • オーケストレータが操作不能になる
  • そのため、コネクションの上限等が設けられているか確認する必要がある

トラフィック制御

  • CaaSではコンテナが動的に展開されるため、IPアドレス等のネットワーク情報も変化する
  • そこにルーティングやポートマッピングを適用するのは簡単ではない
  • また、CaaS上の別ノード間で暗号化通信を行う場合、通信のプロキシコンテナを起動させるパターンがあるが、(ambassadorコンテナパターン)
  • ambassadorコンテナのリソースが余計に必要、またスケール時にオーバーヘッドが発生するなど、問題も起こりやすい

従来のアプライアンス製品との相性

  • 従来のアプライアンスは、CaaSのように動的にコンテナが可動するという用途に合わないものがある(らしい)

監視SaaSの利用時の注意

  • 従来の監視SaaSでは、エージェントあたり100台以上のコンテナインスタンスのメトリクス収集は負荷的な部分で想定されていない
  • その結果、SaaS事業者のDCに過負荷を与えてしまう可能性がある

まとめ

  • 様々なコンテナや周辺技術がCaaSでつながっていくことで、新たに生じる課題も存在する
  • それらを解消し、コンテナとの潜在的価値を発揮できる環境を整備することが大切である