アプリケーションのアーキテクチャを学ぶ¶

サンプルの背景を学ぶ¶

あなたの会社はペットフード会社であり、スーパーボウルのコマーシャル枠を購入しようとしています。コマーシャルでは、視聴者に対して調査のために犬か猫かの投票を呼びかけます。あなたはウェブ投票システムを開発します。

この調査では100万人もの人々が投票してもウェブサイトが止まらないようにする必要があります。結果をリアルタイムで知る必要は無く、結果は会社のプレスリリースで公開します。しかし、どれだけ投票されたかは、投票の度に確実に把握する必要があります。

アプリケーションのアーキテクチャを理解¶

投票アプリケーションは複数のマイクロサービスで構成されます。並列なウェブ・フロントエンドを使い、ジョブを非同期のバックグラウンド・ワーカに送ります。アプリケーションは任意に大きくスケール可能な設計です。次の図はアプリケーションのハイレベルなアーキテクチャです。

全てのサーバで Docker Engine が動いています。アプリケーション全体は完全に Docker 化（Dockerized）しており、全てのサービスをコンテナ内で実行します。

フロントエンドはロードバランサと N 台のフロントエンド・インスタンスで構成します。各フロントエンドはウェブ・サーバと Redis キューで構成します。ロードバランサは任意の数のウェブ・コンテナを背後で扱えます（ frontend01 ～ frontendN ）。Webコンテナは２つの選択肢から投票するシンプルな Python アプリケーションです。キューに入った投票は datasotre 上の Redis コンテナに送られます。

フロントエンドの背後にはワーカ層があり、別々のノードが動いています。この層は次の機能があります。

• Redis コンテナをスキャン
• 投票のキューを回収
• 重複投票を防ぐために投票結果を複製
• 結果を Postgres データベースにコミットする

フロントエンドと同様に、ワーカ層も任意にスケールできます。ワーカの数とフロントエンドの数は、お互い独立しています。

Docker 化したマイクロサービスのアプリケーションを、コンテナ・ネットワークにデプロイします。コンテナ・ネットワークは Docker Engine の機能です。これは複数の Docker ホスト上を横断して複数のコンテナ間で通信を可能にします。

Swarm クラスタのアーキテクチャ¶

アプリケーションをサポートするのは、次の図のように、１つの Swarm マネージャと４つのノードで構成する設計の Swarm クラスタです。

クラスタの４つのノード全てで Docker デーモンが動作します。Swarm マネージャと ロードバランサも同様です。Swarm マネージャはクラスタの一部であり、アプリケーションの範囲外であると考えます。１つのホスト上で Consul サーバはキーストア（keystore）として動作します。これは Swarm ディスカバリ用と、コンテナ・ネットワーク用の両方のためです。ロードバランサはクラスタ内に設置可能ですが、今回のサンプルでは扱いません。

サンプルとアプリケーションのデプロイを完了したら、皆さんの環境は下図のようになります。

この図にあるように、クラスタの各ノードでは次のコンテナを実行します。

• frontend01 ：
  • コンテナ：voitng-app（投票アプリ）
  • コンテナ：Swarm エージェント
• frontend02 ：
  • コンテナ：voitng-app（投票アプリ）
  • コンテナ：Swarm エージェント
• worker01 ：
  • コンテナ：voitng-app-worker（投票ワーカ・アプリ）
  • コンテナ：Swarm エージェント
• dbstore ：
  • コンテナ：voting-app-result-app（投票結果用アプリ）
  • コンテナ：db (Postgres 9.4)
  • コンテナ：redis
  • コンテナ：Swarm エージェント

アプリケーションのデプロイ時、ローカル・システムを設定したら、ローカルのブラウザ上でアプリケーションをテスト可能です。プロダクションでは、もちろんこの手順は不要です。

次のステップ¶

これでアプリケーションのアーキテクチャを理解しました。デプロイするにあたり、どのようなネットワーク設定をサポートする必要があるのか理解したと思います。次のステップでは、このサンプルが使つ ネットワーク・インフラをデプロイ します。