AWSを活用した本番商用環境の構築・テスト自動化の取り組みについて

1. はじめに

TISでは決済領域を強みとしているソリューションブランド”PAYCIERGE（ペイシェルジュ）“を展開しています。PAYCIERGEではアマゾン ウェブサービス（以下、AWS）を活用してシステムを構成することで、高い品質と高速なデリバリスピードを実現しています。また、PAYCIERGEで培ったAWSのノウハウを使って、AWS上でPaaSレイヤのシステム基盤を「高セキュリティクラウド基盤サービス」としてサービス提供型で多くの業界のお客様にご提供し、画面機能やAPI機能などのWeb系システムをはじめとして様々な用途でご利用頂いています。

この基盤サービスはPCI DSSというクレジットカード業界の基準に準拠した高度なセキュリティを担保しながら、サーバレスなどクラウドネイティブな構成を積極的に採用することによりお客様のDX化を推進しています。

近年、世間ではDX推進の動きが高まる中で"システム開発の自動化"というキーワードが注目されています。従来と比べてより一層高い業務効率や生産性、ビジネスの競争力を実現することが求められているなかで、我々はこれまでのシステム導入実績から培ったノウハウを活かして、お客様により早くビジネスを展開して頂くことにより、DXを実現しやすい環境を作ることができると考えています。そのためにシステムの基盤環境のデリバリスピード向上を目指して、構築の自動化に取り組んでいます。

この記事では、自動化の取り組みのなかで実現した、AWSサービスを活用した基盤構築の自動化についてご説明します。具体的な自動化の仕組みについてご説明したうえで、自動化を導入する際に検討が必要だと考える観点についてお伝えします。今回の記事が、システム基盤構築の自動化の導入を検討している方々の参考になれば幸いです。

1.1 これまでの自動化の取り組みと今回の自動化導入の背景

まずは、これまでの我々の自動化の取り組みと今回の自動化を実現するに至った背景についてご説明いたします。

以下表1に記載の通り、AWS環境をIaC(Infrastructure as Code)コードを用いて構築する方式を採用した後、IaCコードの汎用化とシステム構築の標準化を進めてきました。2022年にはAWS Service Catalogを利用した自動構築によって技術検証用環境を約1週間でスピーディーに提供することができるようになりました。

▼表1.これまでの自動化の取り組みと今回導入した取り組みについて

このAWS Service Catalogによる構築自動化の導入によって、検証環境の自動構築を実現した一方で、本番商用環境においても設計から構築までのデリバリスピードの向上が求められるようになってきました。それを受けて今回は本番環境の迅速な構築及びさらなる品質の向上を目標として活動を開始致しました。
この活動の前提として我々基盤サービスチームは、中小規模～大規模なWeb系システム基盤を年間2桁以上構築しています。大規模なシステムだと1年ほどかけて要件定義から移行までをおこなっています。

▼図1.標準的なサービス導入スケジュール

それ以外の特徴として、システム単位・環境（本番/開発）単位でAWSアカウントを新たに発行している点や、多くのシステムで類似するシステム構成を採用することにより、一部の動的な設定項目を変更することで各システムに最適な基盤を素早く提供できるようにしている点があります。基盤サービスチームでは多くのAWSサービスについてAWS CloudFormationテンプレートのひな型を整備しており、その中でシステムごとに変動するパラメータのみ設定値の検討と入力を行い、テンプレートが完成する状態にすることで品質とスピードを両立させています。

多くの類似構成のシステムを扱い、システムごと及び環境ごとに一部のパラメータを変更して構築しているという我々の業務特性から、あらゆるシステム構成に対応する自動化を目指すのではなく、多くのシステムで使われる可能性の高い構成パターンに注力して自動構築の対象とするのが最適と判断しました。

1.2 今回の自動化の対象範囲

前章(1.1)で説明した構築自動化の前提として、基盤サービスチームでは、システム設計における構成を以下図2のように3階層で考えています。
第１階層は、すべてのAWS環境で共通的に実施すべき設定箇所を表しています。具体的な例として、Amazon Guard Dutyで脅威を検出した際に運用担当者へアラート通知を行う機能などが挙げられます。
第２階層は、我々が扱う多くのシステムで必要とされる典型的な構成での設定箇所を表しています。これは単体のAWSサービスではなく、複数のAWSサービスの組み合わせで構成されており、例として以下のようなものがあります。

- AWS Application Load Balancer‐AWS ECS（FARGATE）‐Amazon Aurora
- Amazon API Gateway‐AWS Network Load Balancer -AWS ECS（FARGATE）-Amazon Aurora

第３階層は、案件やシステムごとに必要とされる設定箇所を表しています。案件ごとにシステムの用途が異なりますが、その案件固有のニーズに応えるための設定箇所となります。

このうち、第1階層の共通設定についてはすでに自動化することができています。第2階層のWeb3階層モデルやAPI基盤などの典型的な構成部分を自動化するというのが今回の自動構築の対象範囲となっています。この自動化を実現することにより、第１階層から第２階層までの設定箇所は自動で設定できるようになり、第3階層部分のみに注力して案件対応することが可能になります。

▼図2.システム構成面での今回の自動化の対象範囲

また、今回の自動化する内容を選定するために、下記の表2のような形で我々が新規システムの基盤を構築する際の業務フローを洗い出し、そのうえでどの作業項目を自動化することで価値を最大限に得られるかという観点から考えました。

その結果、No.5～8のIaCコードの作成～実行までの構築の自動化と、No.9の構築後のテスト実施の自動化に選定しました。なお、No.2～4の案件固有部分の設計～設計書作成は、前途したシステム構成のレイヤ分けの中で言うと第3階層に該当する工程を中心に検討する作業項目となっていますので、今回の自動化の対象外となっています。

▼表2.今回の自動化の対象

この章では、今回の自動化に向けた目標と自動化の対象範囲についてご説明しました。自動化の仕組みづくりに取り掛かる前に、チームにとって最適な自動化の在り方や自動化の対象範囲を明確化することで、価値を最大に発揮する自動化の仕組みを形にすることができました。

2. 構築・テスト自動化の仕組みについて

前章では今回の自動化導入の背景について説明しました。ここからは今回実現した本番商用環境の構築及びテスト自動化の具体的な内容について解説していきます。

2.1. 構築自動化によって実現したこと

今回実現した自動化の仕組みのうち構築における自動化で実現したことを解説します。まず、今回の構築自動化のポイントとなるのが、以下3点です。

• 自動構築の対象となる典型的な構成の明確化
• 動的な設定項目についてExcelベースの設定資料からのIaCコード/リソース自動生成
• 自動構築に関する各種機能の細分化

▼図3.構築自動化の仕組み導入後のフロー図

上記のポイントを踏まえて、実際に担当者が実施する作業内容は以下の通りです。

上記の流れにより従来は各担当者がIaCコードのひな型からコードを作成していたところを、Excelベースの設定を記入することで自動的にその内容が反映されたIaCコードの生成・リソース構築が可能になりました。

2.2. 構築自動化の構成

続いて構築自動化の仕組みを実現しているシステム構成について詳しく解説します。
以下の図4のような構成でAWSサービスを活用して実現しており、②～④の機能ではそれぞれ前段の出力情報をもとに自動で各処理が実行されます。ここでは、自動化を構成する①～④の各機能について詳細に説明いたします。

▼図4.自動化の仕組み（詳細）

① システム情報管理Webサイト

この仕組みはユーザが構築するシステムに関する構成情報を登録するためのものです。
AWS AmplifyでWebサイトを構築しています。Webサイト上で入力された情報はAmazon DynamoDBのテーブルに登録されます。

② 作成対象IaCコード抽出機能

この仕組みは①で指定された構成を実現するために必要なIaCの一覧を生成するためのものです。
上記の①でAmazon DynamoDBテーブルにデータが登録されたことをトリガーにAWS Step Functionsが実行開始されます。AWS Step Functions内ワークフローでAmazon DynamoDBに登録されたシステム情報を取得して、必要なAWSリソースの構築順序が記載されたIaC一覧情報がAmazon S3に出力されます。

③ IaCコード自動生成機能

この仕組みは②で生成されたIaCの一覧に基づき、その中で設定すべき内容を設計情報のExcelファイルから自動反映させるためのものです。
担当者がAmazon S3に設定シート及び通信要件一覧のExcelファイルを配置することをトリガーにAWS Step Functionsが実行開始されます。AWS Step Functionsのワークフロー内で②の機能で生成された一覧情報を取得し、汎用化されたIaCコードに設定シートや通信要件一覧の情報を取り込んで、IaCコードをYAML形式で出力します。ここではExcelファイルの値をYAMLフォーマットに取り込んで形式変換をして出力する仕組みが組み込まれています。また、AWS Step Functions内の分岐処理により各テンプレートに合わせて設計情報がIaCコードに入力されるようになっています。

④ スタック自動作成機能

この仕組みは②・③で生成された一覧及びIaCコード群を用いてAWS CloudFormationスタックを自動生成するためのものです。
②・③の情報を所定のS3バケットに格納した状態でAWS Step Functionsを実行開始することによって、③で生成された複数のIaCコードを構築テンプレートとしてAWS CloudFormationにてスタックが自動作成されます。②で出力されたIaC一覧情報をもとに正しい構築順序でAWS CloudFormationスタックを作成実行します。

このように、①～④の機能によって設計から構築までの工程の自動化を実現しています。今後、自動化の範囲や機能の拡張も検討していますが、巨大な１つの自動化の仕組みを作り上げるのではなく、各機能に分けて自動化することで、自動化システムの機能拡張やメンテナンス時に分割して改修しやすい構成としています。これが複数種類のシステム構成を実現しようと考えている我々にとって現時点での最適な自動化の形であると考えています。

2.3. テスト自動化で実現したこと

構築の自動化に続いて、テスト自動化によって実現したことを以下に解説します。一般的にシステム構築後にインフラ観点では以下のテストが実施されるかと思います。

▼表3.システム構築後のテストの種類

上記テストカテゴリの中で単体テストに関しては、今回のテスト自動化の対象には含めていません。その理由は構築の自動化を行ったことによりExcelベースの設定資料の内容がそのままIaCコードに反映されており、それを再度テストの自動化の中で確認する意義が少ないと判断したためです。

具体的なテストケースの自動化基準として、これまでの案件対応実績から案件都度繰り返しテストを行うことで負荷が高いと考えられるケースであることと、AWS環境内に閉じて実施されるテストケースであることを考慮しています。これらの基準を満たすケースは自動化を実現しやすく、また、自動化することによる価値も高いと判断したためです。

具体的に現時点で自動化対象としているテスト内容は以下表4の通りです。

▼表4.自動化対象としているテスト内容

上記テスト内容のうち、今回はNo.1の「コンテナ停止時の自動復旧」のテスト内容について自動化した詳細の構成を2.5にて解説します。

2.4. テスト実施環境の自動構築からテスト自動実行までのフロー

自動テストの仕組みについてはAWS Step FunctionsとAWS Lambdaを用いて開発しており、担当者がAWS Step Functionsを実行することで自動テストが開始されます。また、自動テストを行うにはAWSアカウント単位で自動テストのための仕組みを構築する必要がありますが、AWS Service Catalogを用いることでその点も自動化できています。これらによって担当者は下記図7のA～Cの3ステップを実行することで自動テストの準備・実行・後処理（エビデンス収集）まで行うことが可能となっています。

▼図5.テスト環境自動構築からテスト実行までのフロー図

テスト実施環境も自動化の対象とすることで、自動テスト実施が担当者にとって負荷となることなく対応することが可能です。

2.5. テスト自動化の対象テストケースの「コンテナ停止時の自動復旧」の構成

先に紹介した自動化の対象としているテストケースのうち、「コンテナ停止時の自動復旧」の実行の流れを説明します。AWS Step Functionsのステートマシンを実行することにより以下の処理が自動実行されます。

① 対象のコンテナに対して1秒に1回など定期的に通信を行う（今回の仕組みではAWS Cloud9を通信実行環境として利用）
② 冗長化されたコンテナの1台を停止する
③ コンテナが自動復旧することを確認する
④ ①で実行した通信の実績情報を収集する
⑤ ④の収集結果を出力する

下記図6は、ALB/Amazon ECS(AWS Fargate)/Amazon Auroraを用いたWeb3階層モデルにおいて、コンテナ停止・自動復旧テストを実施した場合の標準的なシステムの概要図を示しています。上記の①～⑤のフローは右側赤枠リソースを使って実行されます。

• AWS Systems Manager Documents
• AWS Lambda
• AWS Step Functions

▼図6.コンテナ停止時の自動復旧のシステム構成

また、このテストの実施結果として、以下2つの観点を確認する必要があります。

A. コンテナが停止した際に自動的に復旧すること
コンテナを強制的に停止し、自動復旧後のコンテナのステータス確認（コンテナ数が通常の台数に戻っていること）を行います。

B. コンテナが停止した際に通信断が発生しないこと（通信断が発生しても瞬断レベルであること）
コンテナ停止前にAWS Cloud9からコンテナに向けての連続テスト打鍵を実施し、停止～復旧の間でどの程度の断時間が発生するかを確認します。

上記の観点でテスト実施結果を確認するために、この仕組みの⑤で実行結果がファイルとして出力され、テストのエビデンスとして取得することができます。
このように、テスト環境の構築から、テスト実施、テスト合否判定までの工程の自動化を実現しています。

3. 導入によるメリット

今回の構築及びテスト自動化を導入した結果、以下のような効果を得ることができました。

① 開発業務の生産性や品質の向上
② 保守運用面での管理負荷軽減
③ 案件固有要件への対応の注力

① 開発業務の生産性や品質の向上

構築自動化やテスト自動化によって、従来実施していた工程を自動実行できるようになり、大幅な作業効率化が実現され、開発業務全体の生産性や品質を向上することができました。
特に、構築自動化のIaCコードの自動生成機能では、システムや環境ごとに設定する値が入力されたテンプレートが自動で生成されるためコードレビューの工程ではレビューが必要なテンプレートとレビューが不要な（自動化されている）テンプレートに選別でき、レビューが必要なテンプレートに注力することでシステム全体の品質を向上することができます。また、テスト自動化に関しても多くのテストケースを実施する際に、予め定義された内容全てをまとめて実施することができるため、品質を維持しつつ高い生産性を実現することができます。更に、テスト自動化のための仕組みを準備する部分までAWS Service Catalogを用いて自動化しているため、準備段階からテスト完了まで全体を通して効率的に行うことが可能です。

② 保守運用面での管理負荷軽減

昨年度の時点ですでに、AWS Service Catalogを用いてAWS環境の自動構築を実現していましたが、AWS Service CatalogはAWS CloudFormationとは異なり、保守運用フェーズにおいてIaCコードを用いて柔軟に環境に変更を加えることが難しいという面があります。そのため、本番商用環境に適用することは難しいと考えていました。
今回実装した自動構築の仕組みでは構築フェーズで自動生成したIaCコードを保守運用フェーズでもそのまま活用できるため、品質を損なわずに保守運用を行うことが可能です。1つのシステムの中で、環境面が複数ある場合にも設定値が反映されたIaCコードが自動生成されるため、複数のコードを管理するにあたっても各コードの整合性を担保でき、システムの安定性と信頼性を担保できます。

③ 案件固有要件への対応の注力

以下の図7に示す通り、自動化導入によって標準的なシステム構成の設計～構築工程にかかる期間を大幅に短縮し、今回の自動化の範囲対象外としている特定システム固有の構成や仕組みの設計に注力することが可能になります。案件固有の要件対応は、特に案件のリスクになりやすいため、短縮した工数を用いて案件特有部分の対応に注力し、潜むリスクに対して適切に対処することで、案件を円滑に進めることが可能になります。そのため、案件全体を成功へと導く1つの鍵となると考えています。

▼図7.自動化後のスケジュールのイメージ

4. 今回の仕組みにおける技術ポイント

ここでは、今回の仕組み導入の際に課題にどのようなアプローチをしたか、今回の仕組みで取り入れた技術的な要素を3点解説します。

課題① 設計情報のIaCコードへの取り込み作業の効率化

従来、設計～構築作業のうちIaCコードへ設計情報を取り込む作業では、リソースごとに数十程のIaCコードを１週間～２週間ほどかけて作成していました。特にセキュリティグループやルートテーブルの通信制御情報は、要件をヒアリングして一覧に整理し、整理した情報をコードに取り込むというような流れで段階踏んでおこなうため、相当の時間を要していました。今回の構築自動化においては設計情報を動的にIaCコードに反映させることで、これまで時間をかけていたこの部分の作業を効率化するということを最大の課題としていました。

この課題へのアプローチとして設計情報を記載したExcelファイルから情報を取り込み、YAML形式でIaCコードを自動生成できる仕組みを構築しました。前述したIaCコード自動生成機能がその機能で、以下の図8の通りAWS Step FunctionsのワークフローでAWS Lambdaを実行しています。以下のワークフロー内の②「設定シート・通信要件一覧チェック」処理で設定シートと通信要件一覧のExcelファイルをインプット情報として取り込み、③「設定内容IaCコード化」処理でYAML形式のAWS CloudFormationテンプレートに変換しています。この②・③ではそれぞれAWS Lambda内でOpenPyXLとruamel.yamlというpythonの外部ライブラリを利用して独自の読取・変換処理を実装しています。

▼図8.IaCコード自動生成のワークフロー

課題② 将来の拡張を見越した自動構築の実装

今回導入した仕組みはあくまで第1.0版という扱いで、今後自動構築に追加すべきコンポーネント（AWSサービス）を拡充していくことを想定しています。自動構築の仕組みを初期リリース後も継続して成長・拡大させるためには、今回開発した仕組みに対して容易な追加・変更ができることが必要と考えました。その解決策としてAWS Step Functionsを用いて、全体のフローをオーケストレーションする構成として各処理を細かくシンプルな単位に分割するというアプローチを採用しています。具体的には、AWS Step Functionsを活用して以下の図9のように、自動構築対象のAWSサービスごとに処理を分散させています。
AWSサービスごとにフローを分散させることによって、個々の処理がシンプルになることに加えて柔軟な構築パターンに対応でき今後構築パターンを拡充する際も既存のAWS Step Functionsのワークフローに並列で処理を追加するだけで、容易にコンポーネントの追加・変更可能となっています。

▼図9.AWS Step Functionsによるフローの分散処理

課題③ 複数システムに対するテスト実行環境の展開

我々は複数のシステムにおいて類似構成を採用するケースが多くあります。そのため今回のテスト自動化では、テスト実施のための環境についてAWS Service Catalogを用いて自動構築することで、複数システムへテスト実行環境自体も自動で素早く展開できるようにしています。これにより“自動テストを行うことが新たな作業負荷とならない”ということを実現しています。これは我々が自動構築・自動テストを推進する上で重要なポイントと考えている1つです。
処理を自動的に行えるようになったとしても、その準備のために多くの時間を割かなければならないとしたらユーザであるAWS環境構築を担うエンジニアにとってトータルの負担は変わらず、結果としてデリバリスピードの向上も達成することができません。自動化を行う際には自動化自体を目的とするのではなく、それによる品質・デリバリスピードの向上や品質の向上といった目的を意識して実現することが重要と考えて仕組みを開発しています。

5. おわりに

この記事では、我々が実現した本番商用環境における構築及びテストの自動化導入までの経緯と自動化の仕組みについて紹介しました。今回、我々が構築・テストの自動化の導入を成功させることができたポイントとしては以下の3点が挙げられます。

1. 自動化のスコープ（対象範囲）を明確化する
2. 組織で培ったノウハウを活用する
3. 拡張性のある仕組みを実現する

1点目については、我々が自動化を検討するにあたって最初に作業項目の洗い出しと優先順位づけを行い、実現する自動化のゴールとして対象範囲を明確化しました。“システム開発の自動化”という言葉は非常に幅広く捉えられがちで、そのスコープが漠然としたまま活動をスタートしてしまうと途中で活動が頓挫してしまったり、成果物を作成しても中途半端なものになりがちだったりするかと思います。
自動化のスコープを明確にするということは言い換えると“処理全てを自動化するのではなく取捨選択する”ということになります。自動化はあくまでも手段であり目的は品質・デリバリスピードの向上といった点にあることを認識して、自動化することの価値が高い部分にフォーカスして活動をすることが必要です。具体的にどの部分にフォーカスするかは組織ごとの業務の在り方によるかと思いますが、今回我々は自分たちの業務を振り返って自動化すべき部分を明確にできたことが今回の自動化の実現につながったと考えています。

2点目については、我々が数年前から継続してIaCコードの汎用化にも取り組んできたなかで、そのナレッジを用いて今回の自動生成を実現しています。またAWS Step FunctionsとAWS Lambdaで様々な処理フローを実現している点も、これまで我々が同様の構成で豊富な実績を保持しており、そのノウハウを十分に活用することができています。このようにこれまで組織として蓄積してきた様々なノウハウを活用することも今回のように大規模な自動化システム開発を実現することができたポイントであると考えています。

3点目については、自動化の構想段階からこの仕組み自体を成長・拡大させていくことが必要になると見越して1つの大きな塊として自動化システムを作るのではなく、機能ごとに細かく分割して実装する方針としています。これにより、機能の追加・拡張が必要になった際も容易に発展させることができます。

上記3つの観点を持って自動化を実現することで我々にとって最適な状態でAWS環境構築の自動化を形にできたと考えています。

本記事では、PAYCIERGEの高セキュリティクラウド基盤サービスが、お客様のDX化を推進するための1つの取り組みとして実現した本番商用環境における構築・テストの自動化について紹介させていただきました。今後、今回の自動化の仕組み活用してお客様に価値をご提供することに加え、更に自動化の機能を拡張させてサービスの生産性や品質のさらなる向上を実現いたします。

著：PAYCIERGE基盤担当チーム
(TIS 株式会社　サービスプラットフォーム事業部　サービスプラットフォーム第1部　エキスパート　二出川弘)
(TIS 株式会社　サービスプラットフォーム事業部　サービスプラットフォーム第1部　シニアアソシエイト　老野春奈)
(AKKODiSコンサルティング株式会社　ICT Solution事業本部　嶋沙織)