連載「ソフトウェア開発自動化入門」のなかで、筆者が執筆を担当した第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回となる今回は、マイクロサービスアーキテクチャにおけるアプリケーション構成のポイントを説明します。

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

         
対象読者 前提知識
エンタープライズ開発者 Java言語及びSpringFrameworkを使った開発に従事したことがある経験者。経験がなければ、こちらのチュートリアルを実施することを推奨します。TERASOLUNAはSpringのベストプラクティスをまとめた開発方法論で、このチュートリアルでは、JavaやSpring Frameworkを使った開発に必要な最低限の知識を得ることができます
GitHubなどのバージョン管理ツールやApache Mavenなどのライブラリ管理ツールを使った開発に従事したことがある経験者
AWS開発経験者 AWSアカウントを持ち、コンソール上で各サービスを実行したことがある経験者
コンテナおよびUnix/Linux経験者 Dockerなどのコンテナ技術を使用した経験がある、またはPOSIXコマンドによるUNIX、Linux系OSを操作したことがある経験者

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

動作対象 バージョン
Java 1.8
Spring Boot 2.1.2.RELEASE
Docker 18.09.2, build 6247962
CentOS 7.6.1810
SonarQube 7.7
SonarLint 4.0.2.3009 for IntelliJ
SonarScanner 3.3.0.1492

将来的には、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とバックエンドに分割しています。それぞれの役割は以下の通りです。

BFFの役割 バックエンドの役割
・サービスマッピング(IP/ポート)
・ブラウザからHTTPメソッド変換(GET/POST⇔GET/POST/PUT/DELETE/OPTION)
・セッション共有(キャッシュサーバ)
・セキュリティ
  ・認証・認可
  ・入力チェック
  ・バックエンドサービスURIの隠蔽
  ・クライアント⇔バックエンドの直接アクセス禁止
・クラウド依存処理の集約(S3アクセスなど)
・RESTfulアーキテクチャインタフェース(GET/POST/PUT/DELETE/OPTIONS)
・Resource Base URI (/api/v1/users/1)
・耐障害性を高めることを目的とした、冪等性の実現
・スケーラビリティを容易にするステートレス処理の実現
・データベースなどセキュリティ的に保護する必要があるリソースへのアクセス

なお、クライアントは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環境のイメージは次のようになります。

構築する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環境を構築する方法を詳述していきます。

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理

金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなどさまざまな開発プロジェクト支援にも携わる。