Dockerコンテナを用いたマイクロサービスアーキテクチャの設計方法

アプリケーション開発のトレンドは、デジタルファースト戦略のもと、あらゆる業界（技術系・非技術系を問わず）をよりクラウドネイティブで分散型のモデルへと導いています。多くの組織が競争力を維持するために、新しい技術と分散型ワークフローを導入しています。 

ソフトウェア開発パイプラインは、チームが効率的に連携し、生産性を維持できるようにします。特に注目すべきは、コンテナ化とマルチクラウド環境を早期に導入した多くの組織が、現在では俊敏性と拡張性の面で主導的立場にあることです。SaaSプラットフォームの開発、レガシーシステムの近代化、継続的デリバリーの支援のいずれにおいても、コンテナとオーケストレーションツールが全体像にどう組み込まれるかを理解することが不可欠です。

Dockerとは

Dockerはオープンソースのコンテナ技術であり、ソフトウェアコンテナのための基盤プラットフォームです。これらのコンテナは、アプリケーションとそのライブラリ、ツール、ランタイムを一つの複製可能なパッケージにカプセル化し、AWS、Microsoft Azure、Google Cloudなどの複数のホスティング環境で一貫して実行できるようにします。

Dockerコンテナは、基盤となるインフラストラクチャに関係なくアプリケーションが同じように動作することを可能にすることで、ソフトウェア開発の世界に革命をもたらしました。 

今日、開発者はDockerを使用してマイクロサービスと呼ばれるモジュールを構築します。これによりパッケージが分散化され、タスクが独立したスタンドアロンの統合単位に分割され、それらが連携して動作します。例えば、全国展開するピザチェーンの開発者は、注文受付、決済処理、調理担当向けの「調理指示票」と配達員向けの「配達指示票」を作成するマイクロサービスアプリケーションを構築できます。これらのマイクロサービスは連携して、全国でピザを調理し配達します。

Dockerアーキテクチャの主要コンポーネント

一般的にDockerといえば、多くの場合Docker Engineを指しています。これはコンテナを構築・実行するためのランタイムです。しかし、Dockerコンテナを実行する前に、Dockerfileを作成する必要があります。

• Dockerfile: コンテナイメージの実行に必要なすべてを定義します。これにはOSのネットワーク仕様やファイルの配置場所も含まれます。  
• Dockerイメージ：Dockerfileを作成したら、Dockerイメージをビルドできます。これはDocker Engine上で実行される、ポータブルな静的コンポーネントです。Dockerイメージは、Dockerコンテナを構築するための指示（またはテンプレート）の集合体です。
• Docker Compose: 主に単一ホスト上でマルチコンテナDockerアプリケーションを定義・実行するために使用され、開発に最適です。ホスト間でのクラスタリングにおいて、Kubernetesは現在標準となっています。 
• Docker Swarm：開発者はDocker Swarmを使用して、Dockerホストのプールを単一の仮想Dockerホストに変換できます。Swarmは、ユーザーに意識させることなく、複数のホストへのアプリケーションのスケーリングを管理します。
• Docker Hub: Docker Hubは、コンテナ化されたマイクロサービスの大規模かつ成長を続けるエコシステムです。数百万のコンテナイメージをホストしており、NGINX、MySQL、Redisなどの人気サービス向け公式ビルドに加え、数千ものコミュニティ管理イメージも含まれています。 

AWS上で運用している場合、Amazon EC2 Container Service (ECS) はDockerコンテナをサポートするコンテナ管理サービスであり、Amazon EC2インスタンスのマネージドクラスター上でアプリケーションを実行できます。ECSはクラスター管理（タスク管理とスケジューリングを含む）を提供するため、アプリケーションを動的にスケールできます。Amazon ECSでは、独自のクラスター管理ツールをインストールして管理する必要もありません。ECSでは、Docker対応アプリケーションの起動と終了、クラスターの状態の照会、およびAPI呼び出しによる他のAWSサービス（例：CloudTrail、ELB、EBSボリューム）やセキュリティグループなどの機能を利用できます。

Dockerにおけるマイクロサービス設計には新たな考え方とアプローチが必要ですが、安定したスケーラブルな統合を構築する比類のない能力を生み出します。 

1}マイクロサービスとは

マイクロサービスは、従来のモノリシックなアプリケーション開発からの転換を表します。開発者は、1つの大規模なアプリケーションを構築する代わりに、それぞれ特定の業務機能を持つ、クラウド上でホストされる専門的なサブアプリケーションを作成します。マイクロサービスはアプリケーションの負荷分散を実現し、複製可能でスケーラブルなサービス間の連携により安定性を確保するのに役立ちます。

では、モノリシックな統合を分解する適切なアプローチとは何でしょうか？アプリケーションをモジュールに分解する際、エンジニアは計画された分解パターンに従う傾向があり、新しいソフトウェアモジュールを論理的な作業グループに分類します。

例えば、ある食料品チェーンの配送・追跡ソフトウェアは、現在果物用に単一のアプリケーションを使用しているが、バナナやオレンジなどを処理するモジュールに分解されることがあります。これにより追跡面は改善されるかもしれませんが、ソフトウェアを論理的なサブドメイン（この例では果物の種類）に沿って分解することは、ビジネス能力に予期せぬ影響を及ぼす可能性があります。

マイクロサービスアーキテクチャの場合、モジュールを構成する上で異なるアプローチを取ります。アプリケーションをビジネス機能ごとに分解し、マイクロサービスの開発、サポート、継続的デプロイを行うためのクロスファンクショナルチームを構築します。マーティン・ファウラーはビジネス中心の分解において「プロジェクトではなくプロダクト」というアプローチを強調しています。パッケージの提供は、完了後に解散するチームによる単発のプロジェクトではなく、優れたプロダクトを継続的に提供するという継続的かつ協調的な取り組みです。

マイクロサービスは、モノリシックなアプリケーション開発に見られる従来のストレージモデルも分散化します。マイクロサービスは、独自のデータストアをネイティブに管理する場合に最も効果を発揮します。具体的には、同一データベース技術の複数インスタンスを複製するか、サービスに最適な形で異なるデータベースタイプを組み合わせる方法が挙げられます。マイクロサービスアプローチの利点は、現在もなお模索されています。したがって、あらゆるシステムと同様に、この手法の潜在的な落とし穴や限界に注意してください。

マイクロサービスアーキテクチャ構築の課題

マイクロサービスの利点にはいくつかの課題が伴います。 

1. サービス追跡：複数のコンテナやホストに分散したサービスは追跡が困難な場合があります。単一の停止点でモノリシックな統合を微調整するのではなく、環境全体に分散した連携するマイクロサービスを一覧化し、迅速にアクセス可能にする必要があります。
2. リソースのスケーリングが迅速：各マイクロサービスが消費するリソースは、モノリシックアプリケーションよりもはるかに少なくなります。ですがアーキテクチャがスケールするにつれて本番環境のマイクロサービス数は急速に増加することを覚えておいてください。適切な管理がなされなければ、多数の小さなホストは単一の大規模アプリケーションと同等の計算能力とストレージを消費することもあります。
3. 非効率な最小限のリソース割り当て：AWS環境を利用している場合、タスクに割り当てられるリソースには下限があります。マイクロサービスは極めて小規模なため、最小限のAmazon EC2インスタンスの一部しか必要としない場合があります。その結果、リソースが無駄になり、マイクロサービスの実際の要求リソース量を超えるコストが発生します。
4. デプロイの複雑性の増加：マイクロサービスは独立して動作し、多くのプログラミング言語で開発できます。しかし、あらゆる言語は独自のライブラリとフレームワークに依存しているため、これらの複数のプログラミング言語には全く異なるライブラリとフレームワークのセットが必要になります。これによりリソースのオーバーヘッド（およびコスト）が増加し、デプロイメントが複雑な考慮事項となります。

しかし、これらの障害は乗り越えられないものではありません。ここでDockerのようなコンテナ技術が介入し、既存のギャップを埋めることができます。

マイクロサービスにDockerが救いの手を差し伸べる

Dockerテクノロジーは、以下の方法を通じてこれらマイクロサービスの課題に対処します。 

• タスクの分離：個々のマイクロサービスごとにDockerコンテナを作成します。これにより、単一のサービスによるほとんど負荷がかからない状況下でアイドル状態にある過剰にプロビジョニングされたインスタンスによるリソースの肥大化問題が解決され、1つのインスタンスで複数のコンテナを実行できるようになります。
• コーディング言語サポート：言語の実行に必要なすべてのサービス（ライブラリやフレームワーク情報を含む）をリンクされたコンテナに分割し、複数プラットフォームの管理を簡素化します。
• データベース分離：ストレージ分離にはDockerボリュームまたは専用データコンテナを使用します。
• 監視の自動化：Sumo LogicなどのツールはDockerと連携し、実行中のコンテナ、ログ、パフォーマンス指標を監視することで、継続的デリバリーパイプラインを実現します。

アーキテクチャを実現するための5つの原則

1. 確固たる基盤を築く。すべては人から始まる。だから、あなたのチームがマイクロサービス環境で生き生きと活動できる準備を整えよう。
2. API優先設計。 各マイクロサービスは、明確に定義されたAPI契約（多くの場合RESTまたはgRPC）を持つべきであり、これがその通信インターフェースとして機能する。API優先でサービスを設計し、疎結合性と発見性を実現する
3. 関心の分離を確保する。 各マイクロサービスは、単一かつ明確に定義された目的を持たなければならない。もし責任を追加すべきだと感じ始めたら、代わりに新しいマイクロサービス（と新しいAPI）を追加してください。
4. テストを通じて本番環境へのリリース承認。 各マイクロサービスに対して包括的なテストパラメータを作成し、それらを統合して継続的デリバリーパイプラインで使用する完全なテストスイートを構築する。
5. デプロイの自動化。 マイクロサービス環境におけるコード分析、コンテナセキュリティスキャン、合格/不合格テスト、その他あらゆるプロセスを自動化。コンテナオーケストレーションツールと継続的デプロイメントパイプラインを活用し、大規模なマイクロサービス管理を実現します。

DockerとKubernetesはどのように関連しているのでしょうか？

KubernetesとDockerはしばしば一緒に言及されますが、コンテナエコシステムにおいてそれぞれ異なる役割を果たしています。Dockerはコンテナランタイムを提供し、Docker CLI、Dockerデーモン、Docker Desktop、Docker Compose、Docker Hubなどのツールを含みます。また、マシンクラスタ間でコンテナをオーケストレーションおよびスケジューリングするためのネイティブクラスタリングツールを提供します。 

一方、Kubernetesは、クラスター全体にわたるコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するために設計されたコンテナオーケストレーションプラットフォームです。これは、本番環境において大規模なノードクラスターを効率的に調整することを目的としています。ポッドという概念を中心に機能します。ポッドはKubernetesエコシステムにおけるスケジューリング単位（1つ以上のコンテナを含むことが可能）であり、高可用性を提供するためにノード間で分散されます。

Kubernetesクラスタ上でDockerビルドを実行することは容易ですが、Kubernetes自体は完全なソリューションではなく、カスタムプラグインを含めることを想定しています。

KubernetesとDockerは根本的に異なる技術ですが、両者は連携して機能し、分散アーキテクチャにおけるコンテナの管理とデプロイを容易にします。 

マイクロサービスへの移行を進める

Dockerコンテナを基盤とし、Kubernetesクラスターを通じてオーケストレーションされるマイクロサービスへの移行により、御社のような組織はよりスケーラブルで、回復力があり、俊敏なアプリケーションを構築できるようになります。コンテナ化戦略とDevOps自動化を組み合わせることで、アプリケーション開発およびデプロイプロセスを近代化できます。

コンテナ管理の詳細については、Sumo LogicのDockerアプリがDockerコンテナとKubernetes環境の監視・最適化を支援し、パフォーマンスと可視性を向上させる方法をご覧ください。