コーセーでは2020年にAWS Lambdaを中心とするサーバレス構成のID基盤を構築、以前からのEC2のシステムを、コンテナを使ったECSにリアーキテクトするなど、モダンアプリケーションの開発に取り組んできた。しかし2023年にID基盤の機能アップデートを行う際、課題に直面したという。同社 情報統括部 DX推進課の池田一樹氏は、課題を抱え続けてきた理由の1つが「クラウド×サーバレス＝モダンアプリケーションだと思い込んでいたこと」だと明かす。12月6日～7日に開催された「TECH+フォーラム クラウドインフラ Days 2023 Dec. クラウドネイティブへのシフト」に同氏が登壇。コーセーが直面した課題とその対応を中心に、モダンアプリケーション戦略の考え方について解説した。

アプリケーションのモダナイズで変化に迅速に対応

池田氏はまず、モダンアプリケーションとは、アプリケーションの設計、構築、管理を継続的に見直し、常に変化を受け入れられるようにする開発戦略のことであるとした。そしてその実現方法として、管理工数を削減できるサーバレス、システムの稼働率を可視化できるモニタリング、部品化した機能を組み合わせて変更の影響範囲を限定したり、リクエストの特性に応じたスケーリングが可能になったりするモジュラーアーキテクチャ、そしてCI/CDによる継続的な開発とデプロイの自動化が可能になるリリースパイプラインの4つを挙げた。

  • 池田氏が示すモダンアプリケーションの定義

これらを実現すると、市場投入を加速できるというメリットがある。構築時間を短縮して迅速にPoCを実施できるため、どの施策が効果的であるかを見極められるためだ。またコストも最適化できる。従量課金でも必要な分だけプロビジョニングすれば良いし、サーバレスなので運用工数も削減可能だ。自動化や管理対象の縮小によってインシデントを削減でき、信頼性も向上する。

「アプリケーションをモダナイズすることで、変化に迅速に対応できる俊敏性を実現することができます」（池田氏）

ID基盤の機能アップデートで直面した課題

コーセーでは2023年から、2020年に構築したサーバレス構成のID基盤について、大幅な機能アップデートに取り組んでいる。このID基盤はAPI Gateway、Lambda、Aurora、AWS WAFを使い、認証、認可などの機能群をECサイトや予約サイトなど外部システムが利用するというものだが、新たに機能を追加するところで課題に直面した。それは1つのLambda関数に機能が集約され、モノリシック化していることだ。ZIP化されたLambdaコードのパッケージには上限250Mというサイズの上限があり、このままでは近い将来上限に達して機能を追加できなくなる。さらに、現状では密結合になっているため、一部の機能改修でも影響は全体に及ぶことになり、運用が非効率な状態になっていた。

また、2021年以降に標準化したアーキテクチャはCodePipelineを使った構成となっていて、ID基盤のデプロイ方法が以前のものと統一されていない点も課題だった。古いID基盤では検証と本番とでライブラリのバージョンに差異が発生するというリスクや、標準化されたパイプラインに準拠していないため、技術的負債が拡大してしまうというリスクがあったそうだ。

これらの課題に対応するにあたり、池田氏は3つのポイントを考慮したという。まず最優先事項となるのがセキュリティの確保だ。そして本番稼働中のシステムであり複数のシステムでAPIが利用されているため、その呼び出し元に影響を与えないこと。さらにプロジェクトでの対応となるためコストと期間も定められていることである。

課題を洗い出し、複数の対応策を比較検討

これらを踏まえて、現環境の再調査と対応策の検討が行われた。まずインフラとアプリケーション両面を調査して課題を洗い出し、対応策については、拡張性、移行コスト、運用コスト、セキュリティの面からメリットとデメリットを整理した。例えば、現状のLambdaにそのまま機能追加する現状維持の対策案なら、移行や運用のコストは増えないが、データベースへのアクセス情報なども全機能で共有されてしまうため、セキュリティに不安が残る。また、ESCコンテナやApp Runnerに移し替える案では移行コストが大きいというように比較した。その結果、Lambdaをコンテナイメージとしてデプロイする案が最有力候補となった。ただしこの案ではLambdaのコールドスタートに課金されるため運用コストが増える恐れもある。そこでコールドスタートの時間を測定して検証を実施。その結果、関数コードが頻繁に更新されないような処理に向いていることがわかり、この案の採用する方針を決めたという。

  • 対応案ごとのメリット、デメリット

最後に、プロジェクトの期間やコストに見合うかどうかが検討された。コンテナイメージLambdaを使うと既存のAPIを置き換える必要があり、周辺システムの設定変更も必要になること、デプロイ方法を変更すると開発期間が長くなることを考慮して、まず既存のまま機能を追加、次にコンテナイメージLambdaへの移行、デプロイパイプラインの統一やセキュリティテストを行うというステップで進める方針を決定した。