.. include:: ../module.txt .. _section-automation-infra-devops-actual-experience-label: 【第1回】マイクロサービスアーキテクチャの基盤・デプロイ自動化 ------------------------------------------------------------------------------------------------------------------------------------- |br| `【連載】「ソフトウェア開発自動化入門」 `_ のなかで、 筆者が執筆を担当した `第４回「基盤・デプロイ自動化」 `_ では、近年のトレンドである マイクロサービスアーキテクチャアプリケーションの基盤構築自動化・継続的インテグレーション・デプロイ(CI/CD)自動化の実現例を紹介しました。 本連載では、そこで紹介した例にならって、アプリケーションの実装とCI/CD自動化、基盤自動化を実際に構築してきます。 具体的には、以下の流れで進めていく予定です。 |br| #. マイクロサービスアーキテクチャでのアプリケーション構成の概要と構築 #. AWS CodeBuildを用いた継続的インテグレーション自動化 * SonaQubeを利用した静的解析環境の構築 * SonaLintを利用した開発端末の設定 * SpringBootにおける単体試験コードの実装 * SpringBootにおける結合試験コードの実装 * AWS CodeBuildとGitHubのWebHook設定 #. AWS CodePipeLineを用いた継続的デリバリ自動化 #. AWS CloudFormationを用いた基盤構築自動化 * VPC環境の構築の自動化 * ロードバランサ構築の自動化 * ECSクラスタの構築の自動化 * セキュリティグループの設定の自動化 * ECSタスク・サービスの構築の自動化 * CodeBuildの設定の自動化 * CodePipeLine環境の構築の自動化 |br| 第一回はマイクロサービスアーキテクチャにおけるアプリケーション構成のポイントを説明します。なお、本稿は以下の前提知識がある開発者を想定しています。 |br| .. list-table:: :widths: 3, 7 * - 対象読者 - 前提知識 * - エンタープライズ開発者 - Java言語及びSpringFrameworkを使った開発に従事したことがある経験者。経験がなければ、|br| `こちらのチュートリアル `_ を実施することを推奨します。TERASOLUNAはSpringのベストプラクティスをまとめた開発方法論で、このチュートリアルでは、JavaやSpring Frameworkを使った開発に必要な最低限の知識を得ることができます。 * - - GitHubなどのバージョン管理ツールやApache Mavenなどのライブラリ管理ツールを使った開発に従事したことがある経験者。 * - AWS開発経験者 - AWSアカウントをもち、コンソール上で各サービスを実行したことがある経験者 * - コンテナ及びUnix・Linux経験者 - Dockerなどのコンテナ技術を使用した経験がある、またはPOSIXコマンドによるUNIX、LINUX系OSを操作したことがある経験者。 |br| また、動作環境は以下のバージョンで実施しています、将来的には、AWSコンソール上の画面イメージや操作、バージョンアップによりJavaのソースコード内で使用するクラスが異なる可能性があります。 |br| .. list-table:: :widths: 5, 5 * - 動作対象 - バージョン * - 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 |br| .. _section-application-architecture-for-microservice-label: マイクロサービスのアプリケーション構成と構築 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |br| マイクロサービスアーキテクチャでは、従来のモノリシックなアプリケーション(全ての機能が一つのアプリケーションパッケージにまとまっている形)に比べ、 アプリケーション構成はもとより、チーム間での開発体制からリリースの単位までこれまでとは異なるかたちで行うことを要求されます。 一般にマイクロサービスアーキテクチャにすることで、以下の様なメリットがあるとされています。 * 各サービスの疎結合性・独立性が向上し、開発のアジリティが向上する * 使用頻度の高い特定の機能を、サービス単位でスケールできるため、アプリケーションパフォーマンスが向上する。 * 独立したサービスの集合でアプリケーションが構成されるため、特定のサービスが障害などで機能不全に陥ってもシステム全体が機能不全に陥ることはなく可用性が向上する。 * サービスのインターフェース(API)が抽象化されることにより、サービスの再利用性が向上する。 ただし、モノリシックなアプリケーションを、機能単位などで単純にサービス分割しただけでは、上記の様な恩恵は得られません。 鶏卵論争ではありませんが、歴史的に見るとむしろ、次々と登場してくるクラウドなどの新しいテクノロジーを活用し、上記の様なメリットを目指して考えられた結果が、マイクロサービスアーキテクチャだったと言えます。 したがって、上記のメリットを実現するには、サービスの分割・アプリケーションの作成・実行単位、プロジェクト構成、開発のスコープやスパン・体制、リリースの最適な単位を、個々のアプリケーションごとに検討する必要があります。 当然、唯一解はないのですが、１つの構成例としては、以下の様なアプリケーションアーキテクチャが挙げられるでしょう。 |br| [アプリケーションの構成] * アプリケーションはAmazon Web Service上に構築するWebアプリケーションとする。 * アプリケーションはフロントエンド(Backend For Frontend: BFF)とバックエンドのサービスに分割し、各サービスはAWS ECSコンテナ上にデプロイされるものとする。 * ECSコンテナ内の各サービスは組み込みTomcatを内蔵するSpringBootアプリケーションで実装する。 * 各サービス間はRESTベースのHTTPリクエストでメッセージ通信を行い、ApplicationLoadBalancerを介して負荷分散する。 |br| .. figure:: img/automation_infra_devops_overview/MicroServiceArchitecture.png |br| この例では、各マイクロサービスはDockerをベースとするECSコンテナ単位で作成していますが、サービスの単位は主に以下の基本原則・考え方により、適切な粒度や分割単位を決定します。 * ビジネスのユースケース * 部門・部署や開発プロジェクト体制ごとの役割分担 * 各サービスの想定ユーザアクセス数 * サービスアプリケーションの規模、性能・パフォーマンス * SLA(Service Level Agreement) |br| また、セキュリティの観点やサービスのスケーラビリティ、ポータビリティ・再利用性を考慮し、サービスを論理的にBFFとバックエンドに分割していますが、それぞれの役割は以下の通りです。 .. list-table:: BFFとバックエンドの役割 :widths: 5, 5 * - 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) * 耐障害性を高めることを目的とした、冪等性の実現 * スケーラビリティを容易にするステートレス処理の実現 * データベースなどセキュリティ的に保護する必要があるリソースへのアクセス .. note:: クライアントはSPA(シングルページアーキテクチャ)で、サーバ側は単純なAPIを提供する場合など、フロントエンド部分をAPI Gatewayなどの商用のプロダクト・サービスで代替する例も多くあります。 |br| 各マイクロサービスがECSコンテナにより管理、ApplicationLoadBalancer(ALB)を介することで、以下のようなマイクロサービスアーキテクチャで考慮しなければならない設計要素をカバーできます。 * ヘルスチェックによるサービス監視 * サービスリカバリ(ヘルスチェックでNGだと再起動) * ロードバランシング * ハードリソース調整/監視(CloudWatch) * パスベースルーティング |br| 上記の構成で実際にアプリケーションを構築する場合は、「 `第４回 ECSコンテナアプリケーションの構築 `_ 」を参考に進めてみてください。 セッションキャッシュやバックエンドのデータベース構築については盛り込んでいませんが、本連載の趣旨からは問題ありませんし、 各々構築方法は、連載「AWSで作るクラウドネイティブアプリケーションの基本」の今後、解説する予定です。 |br| さて、次回以降は、上述のアプリケーション環境を前提とした継続的インテグレーション(CI)環境を以下のイメージのようなかたちで、 AWSのビルドツールであるCodeBuildおよび、SonarSourceにより提供されているオープンソースの静的解析プラットフォームである `SonarQube `_ を使って構築してみます。 |br| .. figure:: img/automation_infra_devops_actual_experience/sample-continuous-integration.png |br| 上記のCI環境では、以下のようなことが実現できます。 * AWS ECSおよびRDS(PostgreSQL)を使って、可用性を考慮したSonarQube環境(今回はフリーのComunity Editionを使用)を構築できます。 * 開発者の端末には、SonarQubeServerから取得したQuality Profie(チェックルール)を使ってコーディング時に静的コードチェックを行えるようにします(1)。 * ソースコードのコミット時に、静的チェックに引っかかっているものがないかSonarQubeのQuality Gate機能を使ってチェックします(2)。 * ソースコードをGitHubへプッシュ・プルリクエスト作成後(3)、WebHook(4)によりAWS CodeBuildが検知、テストおよびビルドを実行し(5)、SonarScannerによる静的チェック結果をSonarQubeサーバへ連携(6)します。 * SonarQube Developer Editionであれば、プルリクエスト時のソースコードレビューコメントに静的解析結果を差し込めます。 |br| 次回はVPC環境内にECSおよびRDSを使って、SonarQubeServer環境を構築する方法を詳述していきます。 |br| 著者紹介 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理 .. figure:: img/automation_infra_devops_overview/pic_image01.jpg 金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。 Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。