Design patterns for container-based distributed systems

オライリー 分散デザインパターン コンテナを使ったスケーラブルなサービスの設計

目次は以下で上述論文と類似している。

  • 第Ⅰ部　シングルノードパターン
    • 2章　サイドカー
    • 3章　アンバサダ
    • 4章　アダプタ
  • 第Ⅱ部　マルチノードパターン
    • 5章　レプリカがロードバランスされたサービス
    • 6章　シャーディングされたサービス
    • 7章　スキャッタ・ギャザー
    • 8章　ファンクションとイベント駆動処理
    • 9章　オーナーシップの選出
  • 第Ⅲ部　バッチ処理パターン
    • 10章　ワークキューシステム
    • 11章　イベント駆動バッチ処理
    • 12章　協調的バッチ処理

Single-container management patterns

従来のコンテナ管理システムの管理インターフェイス（run, pause, stop）では制限が大きかった。コンテナオーケストレーションによってAPI経由で細やかな操作が可能になった。

Upward API

利用者に対して情報を公開するインターフェイス。

  • application-specific monitoring metrics（アプリ固有の監視メトリクス）
  • profiling information of interest to developers（開発者向けのプロファイリング情報）

Downward API

コンテナを制御し、ステートフルなコンテナも適切に管理する。

  • graceful deletion (DockerのSIGTERM→SIGKILLの話)
  • state serialization and recovery (ステートのシリアライゼーションとリカバリ)

Single-node, multi-container application patterns

KubernetesではPods、Nomadではtask groupsと読んでいるコンテナグループのパターン。

サイドカーパターン(Sidecar pattern)

最も一般的なパターン。サイドカー（Sidecar）コンテナはメインコンテナを拡張・強化するためのコンテナ。例えば、メインコンテナがWebサーバでローカルディスク上にログを記録している場合、そのログを収集して永続記憶領域に保存するログセーバー（logsaver）コンテナ。
同じくWebサーバが参照するローカルディスク上のコンテンツをGITリポジトリの変更を検知して更新するコンテンツマネジメントコンテナ。

マルチコンテナ共通のメリットとして以下がある。

  • Webサーバコンテナは安定した低レイテンシの応答を提供しログセーバーコンテナは余ったCPUリソースを使うように構成
  • 異なるコンテナにより別々のプログラミングチームに分けることができる
  • ログセーバーコンテナを他のメインコンテナと組み合わせて使用することができる
  • ログセーバーコンテナがエラーになってもWebサーバコンテナはサービス継続できる(縮退運転が可能)
  • 独立して各機能のアップグレード/ロールバックが可能

アンバサダーパターン(Ambassador pattern)

アンバサダー(Ambassador)コンテナはメインコンテナとの通信を仲介するプロキシとして動作する。
例えば、twemproxyによるアンバサダーを用いることで、アプリケーションはプロキシとのみ通信すればよく、プロキシは複数のMemcachedサーバのシャーディングを行う構成が取れる。

  • localhostの単一サーバに接続することだけ考えればよい
  • スタンドアロンなローカルマシン上のMemcachedを使ってテストすることができる
  • 他のアプリケーションで他の開発言語であっても再利用できる

アダプターパターン(Adapter pattern)

アダプター(Adapter)コンテナは外部からのアクセスに対して、汎用的なインターフェースを持たせることができる。
例えば、モニタリングの共通インターフェースとして、外部に対してメトリックスをエクスポートする。

Multi-node application patterns

マルチノード分散アプリケーション構築のためのパターン。

レプリカロードバランス

シャーディング

ファンクションとイベント駆動処理

散布・収集パターン(Scatter/gather pattern)

並列計算を実行するためのパターン。
典型的には単一リクエストを並列処理し単一応答を返す検索エンジンのようなシステム。
ルートノード(Framework Supplied Root)がユーザ要求を受け、部分計算を行うリーフノード(Developer Supplied Container)で分散処理する。
リーフコンテナの出力を集約するマージコンテナ(Developer Supplied Container)が単一の結果にまとめてルートノードがユーザに返す。

リーダー選出パターン(Leader election pattern)

分散処理のノード間でリーダ選出(典型的なのはレプリケーションにおけるリーダー選出)が必要な場合のパターン。
リーダー選出アルゴリズムのライブラリもあるが、正しく理解して使用することは難しいため、これを抽象化するパターン。
リーダー選出のアルゴリズムは難しいため、アプリケーションにリンクせずに、リーダー選出(Leader election)コンテナとして実装する。
アプリケーションに対してはHTTP APIを利用してリーダ変更を通知する。

Multi-node application patterns - バッチ処理

ワークキューパターン(Work queue pattern)

並列処理可能な大量の処理を実行するためのパターン。
ワークキューのフレームワークは特定の開発言語に依存(例えば、Celery for Python)しているが、これを抽象化して再利用できる。
ユーザからのリクエストは作業コーディネータ(Work Cordinator)コンテナがキュー処理を行い。
作業実行(Work Execution Framework Container)コンテナに振り分けて処理を行う。

イベント駆動バッチ処理

協調的バッチ処理