暇だしDevSecOpsやってみた - CodePipeline Now and Then

こんにちは。LayerX Fintech事業部（兼CTO室）のken5scalです。

こちらは【LayerX Advent Calender 2021】の35日目の記事です。昨日の記事はこちら。

Fintech事業部としての私は、三井物産様らと当社で立ち上げた三井物産デジタル・アセットマネジメントに出向しています。そちらで先日リリースしたプロ投資家様向けのオンライン投資サービス「ALTERNA（オルタナ）」におけるCI/CDのお話をさせていただきます。簡単にサマると、Day1リリース時点でContinuous Integration と Continuous DeliveryをCodeCodePipelineをベースにしただけなのですが、それまでにどういう技術選定を検討したかお話しうようと思います。なお、QAも含めてprdにリリースするという意味でのDeploymentについては未構成です。

なお本件は AWS Startup Tech Meetup Online #9 - Security - connpass で話た内容です。

speakerdeck.com

Alterna DevOps体制

Alterna開発と言いましたが、開発が開始してからは（ほぼ）Ops周りに張りつき、スプリントに参加し以下の対応に携わっていました。

開発スプリントで実現したい機能にあわせたリスク対応
FISCや監督指針に照らしあわした要件の洗い出しとタスク化
AWS Orgの構成から、dev/stg/prdにおけるインフラ構成（含むコンテナ化）
Datadogによる監視と通知構成
Ops周りの運用, フローの作成CI/CDの整備

もちろんTerraform化済みです。

ver0.1 CI/CD

その中でもCI/CDは開発からデプロイまでの作業効率化をするだけでなく、開発者が作ったコードをお客様に提供するサービスに昇華する意味でも重要なコンポーネントです。また金融機関で重要な開発と運用の分離を実装する意味でも、IAMやSecret管理などでの非機能要件も考慮せねばならないため、初期段階から取り組んでいました。その際の初期構成がこの通りです。

f:id:kengoscal:20211118021205p:plain

AWSではECS構成を取っているのですが、ECRのためにわざわざスコープが難しくなりがちな共有アカウントを建てたくありませんでした。そのため、丁度リリースされたGithub Container Registryを活用したろ！という発想で構成したものがこちらです。この場合、コンテナビルドに続くDeliveryもGithub Actionで完結します。シンプルです。

しかし、そのためにはGitHub内でAWS IAMユーザーのシークレットを管理せねばなりません。つまり最終的なプロダクトのセキュリティレベルが、Githubのセキュリティレベルに依存することになってしまいますが、Githubは、その権限設計の大雑把さなどセキュリティに少々不安があります（特に非Enterprise環境は...）。

ver0.2 CI/CD

不安を払拭して、デプロイをAWSに移した構成がこちらです。

f:id:kengoscal:20211118022942p:plain

こちらではGithub Action内でコンテナイメージをビルドし、Github Container Registryにpushする点については変わりはありません。ただ、AWSのCodepipelineを活用してDeployをしています。

最初はこれでもよかったのですが、スプリントが進むにつれて、dev/stg/prdで管理アプリを構築したり、あるいは他プロジェクトが始まるなどあり、徐々にGithubのパーソナルトークン管理に疲弊してきました。ログも出ないし...。

ver1.0 CI/CD

で、最終的に落ち着いた構成がこちらです。

f:id:kengoscal:20211118023733p:plain

各環境にecrとcodepipelineができました。Github Actionはテストやリンターなどのチェックのみに利用されます。この段階でもまだ共有化はしていません。結局のところ、SREやOps関連のチームもまだないため、この段階でさらに管理対象を増やすのは避けたかったためになります。ArtifactsやDelivery方式も含めて今後検討する必要があると思います。