マイクロサービスの基盤構築／デプロイ自動化

連載「ソフトウェア開発自動化入門」のなかで、筆者が執筆を担当した第4回「基盤・デプロイ自動化」では、近年のトレンドであるマイクロサービスアーキテクチャアプリケーションの基盤構築自動化と継続的インテグレーション／デプロイ(CI：Continuous Integration/CD：Continuous Delivery)自動化の実現例を紹介しました。

本連載では、そこで紹介した例にならって、アプリケーションの実装とCI/CD自動化、基盤自動化を実際に構築していきます。

具体的には、以下の流れで進めていく予定です。

1. マイクロサービスのアプリケーション構成の概要と構築
2. 「AWS CodeBuild」「SonarQube」を用いた継続的インテグレーション自動化
　・「SonarQube」を利用した静的解析環境の構築
　・「SonarLint」を利用した開発端末の設定
　・「SpringBoot」における単体試験コードの実装
　・「SpringBoot」における結合試験コードの実装
　・「AWS CodeBuild」とGitHubのWebHook設定
3. 「AWS CodePipeLine」を用いた継続的デリバリ自動化
4. 「AWS CodeStar」を用いた継続的インテグレーション・デリバリ自動化の一括構築
5. 「AWS CloudFormation」を用いた基盤構築自動化
　・VPC環境の構築の自動化
　・ロードバランサ構築の自動化
　・ECSクラスタの構築の自動化
　・セキュリティグループの設定の自動化
　・ECSタスク・サービスの構築の自動化
　・「CodeBuild」の設定の自動化
　・CodePipeLine環境の構築の自動化

第1回となる今回は、マイクロサービスアーキテクチャにおけるアプリケーション構成のポイントを説明します。

なお、本稿では以下の前提知識がある開発者を想定しています。

また、動作環境は以下のバージョンで実施しています。

将来的には、AWSコンソール上の画面イメージや操作、バージョンアップによりJavaのソースコード内で使用するクラスが異なる可能性があります。

マイクロサービスのアプリケーション構成と構築

マイクロサービスアーキテクチャでは、従来のモノリシックなアプリケーション(全ての機能が1つのアプリケーションパッケージにまとまっているかたち)に比べ、アプリケーション構成はもとより、チーム間での開発体制からリリースの単位までこれまでとは異なるかたちで行うことを要求されます。

一般に、マイクロサービスアーキテクチャにすることで、以下のようなメリットがあるとされています。

• 各サービスの疎結合性／独立性が向上し、開発のアジリティが向上する
• 使用頻度の高い特定の機能を、サービス単位でスケールできるため、アプリケーションパフォーマンスが向上する
• 独立したサービスの集合でアプリケーションが構成されるため、特定のサービスが障害などで機能不全に陥ってもシステム全体が機能不全に陥ることはなく可用性が向上する
• サービスのインタフェース(API)が抽象化されることにより、サービスの再利用性が向上する

ただし、モノリシックなアプリケーションを、機能単位などで単純にサービス分割しただけでは、上記のような恩恵は得られません。鶏卵論争ではありませんが、歴史的に見るとむしろ、次々と登場してくるクラウドなどの新しいテクノロジーを活用し、上記のようなメリットを目指して考えられた結果が、マイクロサービスアーキテクチャだったと言えます。

したがって、上記のメリットを実現するには、サービスの分割やアプリケーションの作成／実行単位、プロジェクト構成、開発のスコープやスパン／体制、リリースの最適な単位などについて、個々のアプリケーションごとに検討する必要があります。当然、唯一解はないのですが、1つの構成例としては、以下のようなアプリケーションアーキテクチャが挙げられるでしょう。

• アプリケーションはAmazon Web Service上に構築するWebアプリケーションとする
• アプリケーションはフロントエンド(BFF：Backend For Frontend)とバックエンドのサービスに分割し、各サービスはAWS ECSコンテナ上にデプロイされるものとする
• ECSコンテナ内の各サービスは組み込みTomcatを内蔵するSpringBootアプリケーションで実装する
• 各サービス間はRESTベースのHTTPリクエストでメッセージ通信を行い、ApplicationLoadBalancerを介して負荷分散する

この例では、各マイクロサービスはDockerをベースとするECSコンテナ単位で作成していますが、サービスの単位については主に以下の基本原則／考え方により、適切な粒度や分割単位を決定します。

• ビジネスのユースケース
• 部門／部署や開発プロジェクト体制ごとの役割分担
• 各サービスの想定ユーザーアクセス数
• サービスアプリケーションの規模、性能・パフォーマンス
• SLA(Service Level Agreement)

また、セキュリティの観点やサービスのスケーラビリティ、ポータビリティ／再利用性を考慮し、サービスを論理的にBFFとバックエンドに分割しています。それぞれの役割は以下の通りです。

なお、クライアントはSPA(シングルページアーキテクチャ)で、サーバ側は単純なAPIを提供する場合など、フロントエンド部分をAPI Gatewayなどの商用のプロダクト／サービスで代替する例も多くあります。

カバーできる設計要素

各マイクロサービスをECSコンテナにより管理し、ApplicationLoadBalancer(ALB)を介することで、以下のような「マイクロサービスアーキテクチャで考慮しなければならない設計要素」をカバーできます。

• ヘルスチェックによるサービス監視
• サービスリカバリ(ヘルスチェックでNGだと再起動)
• ロードバランシング
• ハードリソース調整/監視(CloudWatch)
• パスベースルーティング

上記の構成で実際にアプリケーションを構築する場合は、連載「AWSで作るクラウドネイティブアプリケーションの基本」の第4回「AWS ECS上に構築するSpringアプリケーション(1)」を参考に試してみてください。

セッションキャッシュやバックエンドのデータベース構築については盛り込んでいませんが、本連載の趣旨に沿って進める場合は問題ないと思います。各々の構築方法については、連載「AWSで作るクラウドネイティブアプリケーションの基本」のほうで今後、解説する予定です。

次回以降は、上述のアプリケーション環境を前提に、AWSのビルドツールであるCodeBuildおよび、SonarSourceにより提供されているオープンソースの静的解析プラットフォームである「SonarQube」を使用したCI環境を構築していきます。

この構成では、AWS ECSおよびRDS(PostgreSQL)を用いて、ヘルスチェックによるコンテナリカバリ、データの自動バックアップなど、可用性が高いSonarQubeServer環境を構築できる点が大きなメリットです。

構築するCI環境のイメージは次のようになります。

• 開発者の端末では、SonarQubeServerから取得したProfie(チェックルール)を使ってコーディング時に静的コードチェックを行う(1)
• ソースコードのコミット時に、静的チェックに引っかかっているものがないかSonarQubeのQuality Gate機能を使ってチェックする(2)
• ソースコードをGitHubへプッシュ・プルリクエスト作成後(3)、WebHook(4)によりAWS CodeBuildが検知、テストおよびビルドを実行し(5)、SonarScannerによる静的チェック結果をSonarQubeサーバへ連携する(6)

なお、本連載ではフリーのComunity Editionを使用しますが、有償のSonarQube Developer Editionであれば、プルリクエスト時のソースコードレビューコメントに静的解析結果を差し込むことが可能です。

次回はまず、VPC環境内にECSおよびRDSを使って、SonarQubeServer環境を構築する方法を詳述していきます。