💻
暇だしDevSecOpsやってみた - CodePipeline Now and Then
こんにちは。LayerX Fintech事業部（兼CTO室）のken5scalです。
Fintech事業部としての私は、三井物産様らと当社で立ち上げた三井物産デジタル・アセットマネジメントに出向しています。 そちらで先日リリースしたプロ投資家様向けのオンライン投資サービス「ALTERNA（オルタナ）」におけるCI/CDのお話をさせていただきます。 簡単にサマると、Day1リリース時点でContinuous Integration と Continuous DeliveryをCodeCodePipelineをベースにしただけなのですが、 それまでにどういう技術選定を検討したかお話しうようと思います。なお、QAも含めてprdにリリースするという意味でのDeploymentについては未構成です。
Alterna DevOps体制
Alterna開発と言いましたが、開発が開始してからは（ほぼ）Ops周りに張りつき、スプリントに参加し以下の対応に携わっていました。
- 開発スプリントで実現したい機能にあわせたリスク対応
- FISCや監督指針に照らしあわした要件の洗い出しとタスク化
- AWS Orgの構成から、dev/stg/prdにおけるインフラ構成（含むコンテナ化）
- Datadogによる監視と通知構成
- Ops周りの運用, フローの作成CI/CDの整備
もちろんTerraform化済みです。
ver0.1 CI/CD
その中でもCI/CDは開発からデプロイまでの作業効率化をするだけでなく、 開発者が作ったコードをお客様に提供するサービスに昇華する意味でも重要なコンポーネントです。 また金融機関で重要な開発と運用の分離を実装する意味でも、IAMやSecret管理などでの非機能要件も考慮せねばならないため、初期段階から取り組んでいました。 その際の初期構成がこの通りです。
AWSではECS構成を取っているのですが、ECRのためにわざわざスコープが難しくなりがちな共有アカウントを建てたくありませんでした。 そのため、丁度リリースされたGithub Container Registryを活用したろ！という発想で構成したものがこちらです。この場合、コンテナビルドに続くDeliveryもGithub Actionで完結します。シンプルです。
しかし、そのためにはGitHub内でAWS IAMユーザーのシークレットを管理せねばなりません。 つまり最終的なプロダクトのセキュリティレベルが、Githubのセキュリティレベルに依存することになってしまいますが、Githubは、その権限設計の大雑把さなどセキュリティに少々不安があります（特に非Enterprise環境は...）。
ver0.2 CI/CD
不安を払拭して、デプロイをAWSに移した構成がこちらです。
こちらではGithub Action内でコンテナイメージをビルドし、Github Container Registryにpushする点については変わりはありません。ただ、AWSのCodepipelineを活用してDeployをしています。
最初はこれでもよかったのですが、スプリントが進むにつれて、dev/stg/prdで管理アプリを構築したり、あるいは他プロジェクトが始まるなどあり、徐々にGithubのパーソナルトークン管理に疲弊してきました。ログも出ないし...。
ver1.0 CI/CD
で、最終的に落ち着いた構成がこちらです。
各環境にecrとcodepipelineができました。Github Actionはテストやリンターなどのチェックのみに利用されます。 この段階でもまだ共有化はしていません。結局のところ、SREやOps関連のチームもまだないため、この段階でさらに管理対象を増やすのは避けたかったためになります。ArtifactsやDelivery方式も含めて今後検討する必要があると思います。
結びに
上記のようなOpsを最適化するにあたって、Fintech事業部は規模を増やしていかねばなりません。 是非、ご興味がある方は下記のページをご覧ください（募集ポジションも掲載されているので是非）
なお、中のことがワカル、オンラインイベントがちょうど公開されておりますのでこちらもぜひです
明日はCTO室のken5scal さんが何か書く予定です