新規プロダクト開発にサーバレスアーキテクチャを採用
Works Human IntelligenceはERP市場 人事・給与業務分野 シェアNo.1[1]を獲得しているエンタープライズ向け統合人事システム「COMPANY」の開発、販売、サポートを行っている企業である。Works Human Intelligenceによると、COMPANYは国内大手法人の3社に1社にあたる約1200社が導入しており、約510万人の人事データを管理している。同社ではこの膨大な人事データを活用し、より顧客にとって価値のある製品や機能の開発に取り組んでいる。その一つが齋藤氏の紹介する「COMPANY Human Capital Insight（HCI）」である。HCIはCOMPANYやその他外部のシステムと連携し、人事データなどのあらゆるデータを集約。そのデータを元に男女間賃金差異や女性管理職比率などの人的資本にまつわる指標の算出をグラフィカルに表示。さらに自社の指標値を、HCIを利用するすべての会社や同業他社の平均などと比較することができるようになるという。
[1]2021年度 ERP市場 - 人事・給与業務分野：ベンダー別売上金額シェア
出典：ITR「ITR Market View：ERP市場2023」
「この製品は有価証券報告書などを作成する年度末に多くの利用が見込まれるというアプリケーションの特性上、サーバレスアーキテクチャを採用しました」（齋藤氏）
サーバレスアーキテクチャとは、自分たちでサーバーの構築や管理をするのではなく、AWSのAWS Lambda（以下、Lambda）やAmazon DynamoDB（以下、DynamoDB）などのサーバレスのサービスを利用したアプリケーションの構成のこと。サーバレスアーキテクチャを採用することでサーバーのプロビジョニングやスケーリング、メンテナンスなどの面倒な作業から解放され、コア製品の開発に集中することができる」と齋藤氏は語る。一般的にAWSではAmazon API Gateway、Lambda、DynamoDBの構成がよく用いられ、「私たちもこの構成をアプリケーションに取り入れている」と齋藤氏は説明を続ける。
「Serverless Framework」と「AWS CDK」の比較検討
一般的にサーバレスアーキテクチャの構成管理としてよく利用されているのは、「Serverless Framework」である。だが齋藤氏たちは「AWS CDK（以下、CDK）」も検討した。AWS CDKは、AWSのインフラストラクチャをTypeScriptやPythonなどの慣れ親しんだプログラミング言語で構築することのできるツールキット。プログラミング言語で記述するため、for文やif文などの構文が利用できたり、CDKのライブラリからAWSの各リソースが抽象化されて提供されたりしているのが特長。CloudFormationと比較し、圧倒的に少ないソースコード量で構成の管理を行える。またデプロイすると、CloudFormationスタックが作成され、リソースを構築できる。
そこで、齋藤氏は両者の比較検討を行った。CDKはあらゆるリソースがシンプルに、少量のコードで記述できる。またAWSが公式にサポートしているので安心感もある。その一方で、CDKに記述した構成でローカル開発環境を構築するための知見も少ない。またCDKはAWSのリソースしか構築できないため、ベンダーロックインに陥るところも気になる。
一方のServerless Frameworkは、Lambdaなどのサーバレスリソースに限ればシンプルな記述で管理することができることや、さまざまなプラグインも充実しており、容易にローカル開発環境を構築できるというメリットがある。だがサーバレスリソース以外のリソースについては、CloudFormationライクな記述をしなければならない。「CloudFormationはCDKと比較してソースコードの量が肥大化しやすい。とはいえファイルを分割しようとしても分割単位の難しさもある。さらにリソース間の関係が見えにくいという短所もあります」（齋藤氏）
双方のメリットを生かして、サーバレスリソースの構成管理にはServerless Framework、その他のリソールにはCDKを利用するという手も検討した。だが複数のIaCツールを使うとなると双方ともに学習コストやメンテナンスコストがかかったり、デプロイ機構が複雑化したり、新規リソースをどちらのツールで管理するかを考えたりなど、さまざまな面で管理が面倒になる。
最終的に、「CDKはサーバレスアーキテクチャのローカル開発環境をクリアできれば、CDKに軍配が上がる。快適なローカル開発環境を構築しつつ、すべてCDKで管理できる」と齋藤氏は考えたという。またベンダーロックインに関しては「アプリケーション要件として、マルチクラウド構成が求められていない場合は目をつむることはできると思った」と説明する。
齋藤氏たちが開発した製品のAWSアーキテクチャは下図の通り。フロントエンドにはAmazon CloudFront（以下、CloudFront）とAmazon S3（以下、S3）を採用。アプリケーションのバックエンドにはサーバレスアーキテクチャを採用し、APIエンドポイントごとに1つのLambdaを割り当てている。また大規模データを処理する製品のため、ETL処理にはGlueとRedshiftを利用している。
「ここではバックエンドのサーバレスアーキテクチャにフォーカスして説明したい」と齋藤氏は前置きし、CDKのアーキテクチャソースコードの紹介を始めた。エンドポイントごとにLambdaリソースの定義が必要になるので、1つのファイルの中でソースが肥大化しないような構成にしたという。
齋藤氏たちが開発している製品は新規プロダクトであることから、速度が重視される。よってチームも2～3人のフルスタックエンジニアで構成された。「各開発者が1つの機能をシームレスに開発できると効率的だと考えた」と齋藤氏は話す。
E2Eな開発をローカルで完結！ AWS CDKを用いた開発環境の構築
このような前提条件を踏まえたうえで、齋藤氏たちが理想のローカル開発環境としたのが、フロントやAPIで分業しやすい環境ではなく、フロントからAPI、永続層までを含むE2Eな開発が行えることだった。
API GatewayとLambda部分のローカル開発環境について、齋藤氏はCDKのソースコードを公開し説明を行った。そのソースコードが次の図である。認証・認可のためのAuthorizer、Rest APIのためのAPI Gateway、APIのパスのまとまりとしてAPI Constructを定義。Constructの中ではさらにLambdaを定義し、API Gatewayのリソースとの紐付けを行う。
このAPI Gateway、Lambda部分のローカル環境は、AWS SAM CLIを利用し、次の3ステップで構築している。
第1ステップはcdk synthコマンドによる、CDKのコードからCloudFormationのテンプレートの出力である。ここではスタックごとの実行で時間を短縮するため、--exclusivelyオプションを指定し、スタック間の依存を無視し、対象のスタックのみsynthするようにしたり、各コマンドの末尾に&を記載し、バックグラウンドプロセスとして並列実行している。またスタックごとにテンプレートファイルを出力。APIスタックのテンプレートファイルであれば、API GatewayとLambdaの構成の起動のために利用されるなど、後続のステップで利用される。
第2ステップはsam buildコマンドによる、各Lambda関数のDockerイメージのビルド。LambdaのDockerイメージのビルドでは、--parallelオプションを指定し、並列実行により時間短縮できるようにしている。またDockerイメージはソースコードを含むため、ソースコードの変更のためにビルドする必要がある。「これを毎回手動で行うのは手間なので、VS Codeの『Run on Save』という拡張機能を利用し、ソースコード保存時にsam buildが実行されるようにすることで、擬似的にホットリロードを実現している」（齋藤氏）
第3ステップはsam local start-apiコマンドによる、API Gateway、Lambdaの構成を起動。標準出力されるログは読みづらく、永続化されないため、--log-fileオプションを利用しファイルへのログ出力を設定。また23年4月にリリースされたバージョンよりsam local start-apiコマンドがLambda Authorizerに対応。これにより、ローカルでもクラウドの環境に近い構成が再現可能できたという。
永続層であるDynamoDBのローカル環境構築については恋塚氏が説明してくれる。
DynamoDBのCDKソースコードは次のようになる。「DynamoDBStackというスタックを作り、その中でusersテーブルを定義する際は、TableとGSIに関する記述を行っています」（恋塚氏）
DynamoDBのローカル開発環境も自作スクリプトを利用し、次の3ステップで構築している。
- 公式のDockerイメージからDynamoDB Localを起動
- cdk synthコマンドを利用して、CDKのコードからCloudFormationのテンプレートを出力
- テンプレートを元に、自作スクリプトによるDynamoDB Localへのテーブル作成を実施
自作スクリプトはPythonで記述した約80行のシンプルなもの。「サードパーティのライブラリもあるが、スクリプト自体が小さく、メンテナンスされていない可能性もあるので、自分たちで自作して管理する方が柔軟性も得られるので、良いと判断しました」（恋塚氏）
実際にサービスを運用する中で、さまざまな課題にも直面したという。最初に直面したのが、CloudFormation Sackのリソース上限問題である。「半年の開発で1つのスタックに宣言できるリソースの上限である500に迫る勢いでAPIリソースが増えていった」と恋塚氏は明かす。この課題を解決するため恋塚氏が取った方法は「NestedStackを利用し、APIの親パスごとにスタックを分割すること」だった。スタック数がAPIの親パスレベルで増えてしまうというデメリットについては、ソースコードに少し変更を加えるだけで対応できたという。
次に直面した課題は、$sam local start-apiがNested Stackに対応していなかったことである。そのため、URIにおけるARNの解決ができず、ローカル環境が構築できなかった。
この課題に対しては、「CDKのソースコード上で、ローカル用とクラウド用でAPI Gatewayに紐付けるLambdaの指定方法に変更を加えることで解決しました」と恋塚氏。そうすることで出力されたテンプレートで、Fn::GetAttが使われなくなり、$sam local start-apiが意図通り動くようになったという。
その他にも恋塚氏はCDKとサーバレスアーキテクチャを使った開発におけるティップスを紹介。例えばコールドスタート対策として、よく利用するAPIについてプロビジョンドコンカレンシーを使用してウォームアップすることや、Lambdaアーキテクチャについては、AWS CDKスクリプト内で動的にアーキテクチャを決定し、開発者間の実行環境に依存しないようにすること、各開発者の専用クラウド環境については、stageという概念を用いて1つのAWSアカウント内に各開発者専用の開発環境を構築することなどを伝授した。
恋塚氏は最後に「AWS CDKとサーバレスアーキテクチャはかなり相性の良い組み合わせだと思っている。ぜひ、皆さんも機会があればトライしてほしいと思います」と呼びかけ、セッションを締めた。
