分散システムデザインパターン読書メモ1

シングルノードパターン

1つのインスタンスの中でメインのコンテナと他のコンテナを組み合わせるときのデザインパターン

  • サイドカーパターン
    • メインのコンテナに機能を付与したり、改善したりするためのコンテナを組み合わせる
    • 例) gitリポジトリへのpushによって、コードをデプロイする機能を追加するコンテナ 
      - gitリポジトリを定期的にpullして、アプリケーションのコンテナと共有したパスにgit pullしたコードを反映させる
  • アンバサダーパターン
    • メインのコンテナと他とのやり取りを仲介するようなコンテナを組み合わせる
    • 例) メインのコンテナに変更をいれることなく複数memcachedをシャーディングする
      • メインのコンテナはlocalhostのmemcachedに接続する設定のまま、memcachedの代わりに接続先として追加したコンテナがいくつかある外部のmemcachedにシャーディングするようにする。例ではアンバサダーコンテナに twemproxy /を利用していた。
  • アダプターパターン
    • メインのコンテナのインターフェースを規格化した統一されたものにするためにコンテナを組み合わせる
    • 例) 監視用のメトリクスの出力(送信)(prometheus)
    • 例) ログデータの出力(fluentd)
      • メインのコンテナのログ出力形式は同じとは限らない。ログファイルへの出力だとしてもJSONや、LTSVなどフォーマットは異なる。それを一定のフォーマットに変換した上でログの集約や送信時のバッファリングの機能を追加することを可能にする

分散デザインパターンのマイクロサービスへの活用

パターンを使うことでシステムデザインがしやすくなる。同じパターンを開発者感で共有することでデバッグしやすくなる。 分散デザインパターンを使う・知ることでマイクロサービスにおけるデメリットを補うことができる。

  • メリット
    • 分割した個々のサービスごとにスケールの方法を選択することができる。
    • スコープが狭まることでピザ二枚分の小さな開発チームに保つことができることで、様々なオーバーヘッドを減らすことができる
  • デメリット
    • システムが疎結合になることで、問題発生時のデバッグの難易度があがる
    • システム間の連携や、適切なシステムの分割などシステムデザインの難易度があがる

マルチノードパターン

レプリカがロードバランスされたサービス

  • ステートレスなサービス
    • ステートレスな複数のサーバーとその前段にロードバランサーを配置する組み合わせ
    • 負荷の分散、耐障害性の向上
    • 可用性を高めるためには最低でも2つのレプリカが必要なる
    • 各レプリカにはロードバランサーに組み込めるかを判断するためのRedinessProbe(ヘルスチェックエンドポイント)を作っておく
  • セッションを保存するサービス
    • ステートレスなサービスに合わせて、特定のリクエストを同じマシンにルーティングを行う
    • 特定のマシンに送ることでキャッシュのヒット率を向上させることができる
    • 単なるIPアドレスによるハッシュではなくコンシステントハッシュを使うことでレプリカの増減時(scaleout,in)にマッピングの変更を最小限にすることができる。
    • コンシステントハッシュ？
  • アプリケーションレイヤでレプリカを扱うサービス
    • TCP/IPのレイヤーより高いレイヤー(httpレイヤー)でのロードバランスすることでより踏み込んだ制御が可能になる
  • キャッシュレイヤーの導入
    • アプリサーバーの前段にキャッシュレイヤーを設けてリクエスト処理の効率化を行う
    • varnishを使ったパターン
    • リクエストの流れ
    • 各レプリカのサイドカーとして配置することもできるが台数が増えるほどキャッシュ効率が悪くなる
    • レプリカレイヤーの前段に配置するのが自然
  • キャッシュレイヤーの拡張 -帯域制限とDOs攻撃に対する防御 
    - varnishってhttpリバースプロキシだったのかキャッシュサーバーだと思ってた
- throtleモジュールを使うことで、DoS攻撃を防御することができる
    • SSL終端
      • nginxを使う
      • SSL終端レイヤー => キャシュ => Appサーバー