分散システムデザインパターン
https://gyazo.com/d049c9fdf618f253dbc3b078ea16ca01
Kubernetesの開発者で現在はMicrosoftでAzureの開発をしているBrendan Burns先生が書いた,k8sにおける,コンテナを使ったサービスのデザインパターン.
コンテナを使ったよくあるパターンに名前が付けられていてそれらがどういうことを指すのか書かれていてとりあえず読んでおけば,k8sとか使ってサービスの設計したりしてる人の用語が分かったりして便利かもしれない.
kimitoboku.iconとりあえず,読んで随時更新していく.
目次
はじめに
シングルノードパターン
ここでシングルノードというのは,1つのマシンの上で動作し,ローカルホストやファイルなどを共有出来るコンテナ間でのパターンを意味している
kimitoboku.iconk8sではPodという単位に相当すると考えると楽
サイドカー
実際に動作するアプリケーションとそれを補助するサイドカーコンテナによって動作する
例えば,Webアプリケーションを動作させるとして,その配信するファイルなどを自動で更新する機能などを追加したいとする.
ここで,Webアプリケーションに手を入れて自動的に所得する機能を付けるのは良いが,そうすると,Webアプリケーションの機能が増え続けることになったり,また,Webアプリケーションが古くて手が入れられないこともある.
そこで,サイドカーパターンえでは,このWebアプリケーションが動作するコンテナとディスクを共有するサイドカーコンテナを作成する.
このサイドカーコンテナの中でファイルの自動更新を行うスクリプトを作成する.
サイドカーコンテナによって,本体のアプリケーションには手を入れずに機能を増やすことが出来る.
このようにメインの機能を持ったWebアプリケーションにサイドカーのように付属することで,機能を増やすパターンをサイドカーパターンと呼ぶ.
kimitoboku.iconこのパターンは便利で,例えば,Webサービスの動いて居るコンテナのCPU使用率などを確認するサービスを作りたい時は,プロセスIDなどを共有するコンテナを用いて作れば良いし,コンテナのネームスペースの共有機能を使って機能を増やせるという発想を最初にした人は天才だなぁと思う.
アンバサダ
アンバサダパターンは,コンテナで実行するアプリケーションから外部のリソースにアクセスするためのとりまとめを行うためのパターン
例えば,Webアプリケーションをコンテナで動作させる時に,Webアプリケーションから外部のMySQLなどのデータベースにアクセスすることになる.
このアクセスを仲介するこんてながアンバサダコンテナになる.
アプリケーションコンテナとアンバサダコンテナはネットワークを共有するので,localhostの決まったポートにアプリケーションはアクセスするだけで,データベースなどの外部のリーソースに固定してアクセスすることが出来る.
アンバサダコンテナは外部リソースへのアクセスを仲介する.
外部リソースは環境によってアクセス先が変化する可能性があるので,その変化をアンバサダコンテナが吸収する
アンバサダコンテナはサービスディスカバリを行ったり,ロードバランスの機能を持たせたりしてもよい.
kimitoboku.iconアンバサダパターンを使えば,ローカルの環境で開発する時と,サーバで動作させる時で,アプリケーション側のコードは一切変化させることなく実行出来る.それでいて,拡張性も作れて便利.
アダプタ
アプリケーションが外部リソースからアクセスされる時に,変換アダプタのように動作するパターン
例えば,PowerDNSなどのOSSアプリケーションには,統計情報を出力する機能が存在する
しかし,これらの出力が,現在使っているログ収集システムのフォーマットに合致しない可能性がある
そこで,アダプタパターンを用いて,外部からのアクセスをアダプタコンテナが仲介してフォーマットの変換などを行う
アプリケーションに手を入れずに,サービスをつなぎ合わせるのに便利なパターン
kimitoboku.iconOSSなどに手を入れるのは現実には困難なので,使い勝手がいいパターンな気がする
マルチノードパターン
レプリカがロードバランスされたサービス
実際に動作するサービスがステートレスの場合のパターン
これは,基本的にロードバランサーで適当に分散してしまえばいいパターン
同じユーザが同じサーバに接続した方が良い場合は,ロードバランサーのハッシュにコンシステントハッシュを用いた方が良い
ロードバランサーの基本的な使い方
シャーディングされたサービス
実際に動作するサービスがステートフルな場合のパターン
例えば,コンテンツをキャッシュするサービスを考える
このキャッシュを複数台立てる時に何も考えずに,適当にローバランスすると,キャッシュの容量を増やすことは出来ない
そこで,アクセスしてくるリソースに応じてハッシュするなど,同じコンテンツに対するアクセスは同じキャッシュサーバを経由しよう
シェーディングされたサービスをなサービスをロードバランスする時は,どのように振り分けるかを考えてハッシュしましょう
スキャッタ・ギャザー
ファンクションとイベント駆動処理
課題
通信はネットワークを通じてのみ行われ、すべてのデータはストレージサービスに配置する必要があり、サービスの全体像の把握などを難しくする
ファンクション間の繋がりを正しく考えないと、無限ループに陥りやすく、その存在にも気付きにくい
FaaSが成熟すれば問題なくなる可能性は高いが当面は監視などを密に行う必要がある
デコレータパターン
FaaSは入力を受け取りそれを出力に変換して他のサービスに受け渡す。
この動作で他のサービスとの間でHTTPリクエストを送りその出力を拡張したり、フィルターを行なったりする。
Pythonのでデコレーターのようなパターン
よく使われるのがHTTPのリクエストを受け取り、デフォルト値を入れてバックエンドのサービスに再度リクエストを行う
パイプラインパターン
非同期に行う処理をパイプラインとして構築する
ユーザ登録->メールの認証
ユーザ登録->初期データの作成
といった形で処理のパイプラインをファンクションとして作っていく
オーナシップの選出
バッチ処理パターン
ワークキューシステム
イベント駆動バッチ処理
協調的バッチ処理
まとめ: 新しい始まり?