eurekaにおけるここ一年のTerraform Component Delivery Processの変化 ~急成長していくProduct基盤のProductivity,Security,Privacyとの向き合い方~
はじめに
この記事は「Eureka Advent Calendar 2020」14日目の記事です。
前日の記事は同じSRE Team の@marnie さんでCloudfront+Lambda@edgeを利用してサーバーレスに画像をリサイズ・変換して返却するCDNを構築したお話でした。
こんにちは、はじめまして、もしくはお久しぶりです。今年の3月からeureka SREチームでエンジニアをやっている @fukubaka0825 a.k.a nari です。
最近はフルリモートで働けることもあり、いったん1年半くらい住んでいたギークハウスというシェアハウスから離れてgoodroom ホテルパスつかってワーケーションを満喫したり、Oculus quest 2買ってfitxrで運動解消したり、巷で話題のM1に夢中になっています。もちろんManzai 1の方です。
ここから好きな東京芸人(さらば青春の光、蛙帝、ニューヨーク、オズワルドetc)の話をしていきたいところではありますが、どうやらこれはTech系のAdvent Calendarらしいので同じくらい好きなTerraform、特にInfra ComponentのDelivery Processのここ一年での変化の話をしていこうと思います。
(自分が入社から注力しているSelf-Service化全体の話をしようと思っていましたが、分量が大変なことになりそうだったのでまずはInfra Delivery Processの話に絞ってお話ししようと思います。)
対象読者
- IaC(Infra as Code)(Terraformというツールである必要はない)をある程度実践している/していきたい方
- Terraform Cloud/Github Actionsを用いたCI/CD基盤に興味がある方
- Infra Component並びにStoreするお客様の個人情報データに関して、Security/Privacy観点での継続的改善をDelivery Processへ落とし込んでいく具体例が知りたい方
前提 ~弊社のProduct及びTerraform Component事情~
弊社eurekaは、2012年10月にローンチしたオンラインデーティングサービス「Pairs」と2019年7月にローンチした「Pairsエンゲージ」を展開しています。
私たちのコアサービスである「Pairs」は、日本でも急成長中のオンラインデーティングサービス市場において国内最大級を誇り、現在、日本と台湾・韓国を合わせて累計会員数1,000万人を突破しています。
そんなプロダクトのInfraは基本的にAWS上に構築しており、Data基盤はGCPも使用しております。IaCツールとしてTerraformを採用しており、Terraformでコード管理しているCloud Providerは2020/12現在AWS(16アカウント)、GCP、Fastly、DataDogの4つです。(弊社のTerraform AWS Component事情は、同じSRE Teamの Daichi Harada さんの TerraformによるAWSマルチアカウント管理 in eureka, Inc. をんでいただけると詳しくお分かりいただけるかと思います)
累計のTerraform Componentの数は140を超えるまでになっていて、日々プロダクトの成長/増加に伴って増えていっており、これらはMono Repoで一括管理してます。Moduleを含めたComponentの複雑性もプロダクトの成長と比例しどんどん増幅していっています。
また、デーティングサービスのリーディングカンパニーとしての社会的責任や事業の安心・安全へのニーズにより、プロダクトを支えるInfra Componentに関してもSecurity/Privacy観点での継続的改善を実現していく必要性がありました。(弊社のSREでのSecurity関連の取り組みに関しては、Infomation DirectorであるOndaさんのSecurity / AuditabilityをSREチームの成果指標に加えた話 をご参照ください。)
以前のプロセスの紹介、問題点
まずは以前のプロセスに関して紹介し、問題点を見ていきましょう。
Infra Develiery Process(Before)
問題点1.Productivityの悪化(リードタイムの悪化)
前述の通り、Moduleを含めてコンポーネントの複雑性はProductの進化/増加と共に加速して行っているため、あるModuleをいじったときの影響するコンポーネント数が増えていき、手動での適応にどんどん時間がかかるようになっていました。
また、tfstateをgithubで管理していたため、conflictが起きた際の解消で時間がとられてしまったり、あるリソースが管理から外れてしまったりといった影響がありました。
また、tf opeataion用の大きな権限をdeveloperへ与えることはできないため、developerがtfコードを書いてpull requestを送ってくれたとしても、self-serviceでdeliveryまで(もちろん垂直分掌をまもるため、SRE reviewは必須ではある)持っていくことができない状態でした。
以上のように、Infra ComponentのOperation関してProductivityが高い状態とは言えませんでした。
問題点2.Security考慮したCode Reviewがもれなく行われる必要性を満たせない(Best Practiceにのっとる/データの暗号化)
前述のように、安心・安全へのニーズを満たすため、AWS Best Practice/PCI-DSS準拠していく方針になったり、親会社であるMatch Group のPolicyを適用し、ある性質の個人情報に関しては暗号化して保持しなければならなかったりとSecurity面で考慮/Reviewしなければならないポイントが増えてきました。
そういったReviewをSecurity/SRE teamがつどつどしていくというのは現実的ではなく、Policy as CodeのようにPolicyに違反する箇所はリリース前に自動的に指摘してくれるような仕組みが必要になってきました。
問題点3.Privacy(お客様の個人情報への考慮)を加味したData Storeの作成/変更へのreviewがもれなく行われる必要性が満たせない
こちらもSecurity同様、Match Group全体で標準化されているデータの保持期限Policyに準拠するなどなど、PIへの取り扱いへのケアの考慮点/工数はますばかりで、こちらもReview漏れがおきない仕組みが必要になってきました。
変更後プロセスの紹介
この問題点を改善すべく、ここ一年でSRE with Sec teamで協力して改良を行った、変更後のプロセスに関して紹介します。
Infra Delivery Process(After)
変更ポイント1. terraform cloud/Github actions によるCI/CD pipelineの導入
特徴
- Terraform CloudはTerraformの構成ファイルをクラウド上で管理、これに基づいてチームによるワークフロー自動化、コラボレーション、ガバナンスを提供するサービス
- PlanはFree/Team & Governance/Business の3つ
- OrganizationはOrganization > team > user という構成。Team & Governance planであれば、DefaultのOwner Team(全てのopeが可能)以外も作成可能で、Developerへも権限を絞った上でアカウントを作成できる
- Team & Governance planからSentinel(Policy as Code tool)を使用できる
- 認証機能に関しては、Business planからSaml認証対応。2FA認証はどのplanでも対応
選定理由
- tfstate置き場としても利用できる
- CI/CD用のymlの管理が不要
- 一つのAdminアカウントのみであれば、Free planで無料で使える(20201214現在、5 accountまで無料)
- backend.tfにて、organizationと、workspace(1tfstateにつき一つ)を指定してあげるだけでtfstate置き場として認識してくれる(指定した名前のworkspaceのがない場合、作成してくれる。ただし、CI/CDをterraform cloudで行わない場合、Execution ModeをRemoteからLocalにする必要あり)
当初はCI/CDもterraform cloudで動かしていましたが、弊社のMono RepoのSource Volumeが大きすぎてSet up phaseで10分ほど待たされるケースも出てきてしまったため、CI/CD機能に関してはGithub Actionsへの移行を決定しました。(サポートに問い合わせたところ、これはfreeプラン以外でも起きてしまうようでした。)
選定理由
- 弊社がGithubをSorce Code Hosting Serviceとして採用しているため、無料で使え、かつCIのSet up phaseも短い(現在長くて1分ほど)
- terraformが公式のactionsを出している かつ terraform cloud credentialも対応しているため、非常に記述が楽
- 公式actionで簡単に、pull requestにCI結果をコメントできる(Developerもこちらの結果を見て確認/修正が可能)
これによって、問題点1.Productivityの悪化(リードタイムの悪化)に関してはある程度の改善策を打つことができました。以前のリリース頻度を定量的に取得することができないので数値で示すことはできませんが、少なくともdeveloperが自身で変更をmergeをして反映できる世界にすることができました。また、手動Local DeployではできなかったCI後のDeliveryに関しても担保できるようになりました。(12 app factorのCode Baseの世界の実現)
変更ポイント2. bridgecrew botの導入
bridgecrew とは、IaC CodeをOver 400 built-in policiesなどのPolicyにそぐわない箇所を検知し修正してくれるPlatformで、bridgecrewのOSSツールcheckovのPoCを行った後に、12日目の記事をかいたSecurity teamのKenniによって導入されました。
以下のような特徴があるとされています。
- Get continuous visibility into AWS, GCP, and Azure misconfigurations as well as violations in Terraform, CloudFormation, and Kubernetes.
- Automatically fix misconfigurations in run-time and build-time with automated playbooks and merge-ready pull requests.
- Over 400 built-in policies cover security and compliance best practices for AWS, Azure, and Google Cloud.
- Scans Terraform, CloudFormation and Kubernetes, Serverless framework, and ARM template files.
How to Use
- Policyにそぐわない箇所への指摘pull requestが以下のようにbotからくるので
- Guidelinesに掲載されているRemediationを参考に修正します(今後、Pull Request Commentにremediationのボタンが実装される予定だそうです。)
- Policy項目ごとの対応状況に関してもDash Boardで確認することができます
これにより、問題点2.Security考慮したCode Reviewがもれなく行われる必要性を満たせない に関しては、自動でPolicyに則ってReviewして貰える環境を手に入れることができ、ある程度改善することができました。当面は既存のPolicy違反の数を0に近づけていくようにSecurity with Sre teamで動いていく予定です(SLI/SLOの指標としても保持を検討中)
変更ポイント3. Service Deskの導入
こちらもSecurity teamのKenniによって導入されました。こちらの導入によるメリットは、差し込みタスクの流量の可視化が行われたのもありますが、今回の文脈では個人情報関連のInfraへのRequestをもれなくReviewし適切な対応ができるようになったことにあります。(こちらはDeveloper自体がpull requestを出す場合もReview依頼として発行してもらっています。)
以下のように、AWS S3/DynamoDB/RDSなどのData Storeの追加/修正のチケットのinputに個人情報の有無のcheck boxを設定しています。
こちらの値がYESの場合、Match Group全体で標準化されているデータの保持期限Policyごとにデータをマッピングしてmaster data管理しているgithub repositoyへpull requestをおくってもらうようにしています。(Policy適用batchへの反映は別途行う)。またData Store Resourceに対して、Policyに則ってData SensibilityをTerraformソース上でtaggingしてもらい、特定の性質のデータの場合、暗号化の設定をしてもらうようにReviewしています。
これによって問題点3.Privacy(お客様の個人情報への考慮)を加味したData Storeの作成/変更へのreviewがもれなく行われる必要性が満たせない も改善することができました。
今後の展望(infra delivery process)
1.terraform CI/CD基盤リニューアル
現状のGithub ActionsでのCI/CD基盤には以下の2つの課題があります
- 非常に強い権限を持った AWSの credential が発行され、それが Github Secretsとして保存されている
- コンポーネント追加する際につどつど対応するGithub Actionsのymlを追加する必要がある
最近同じような課題感で、CodeBuildに移行したQuipperさんの事例(Terraform の CI/CD を CodeBuild に移行した話)がありましたが、弊社はModuleも同じrepoで管理しているため、そこの差分も検知してCI projectをキックしたい場合、どうしても個別にymlを作成する必要があるという別の課題も存在しているため、参考にしながらうまくよりいい仕組みに載せ替えて上記の課題を解決したいです。
また、DeveloperがCloud RequestをService Desk経由ですると、その情報をもとにpull requestが作成されたりすると、手間が省けて良さそうだなとも考えています。
2.チュートリアル/Workshopなどを用意して、もっとtfを書けるDeveloperを増やしていく
現在AWS DynamoDB/S3/SQS 新規作成などこちらで参考Pull Request Templateを用意しているもの以外は、もともとナレッジがあるDeveloperからのみPull Requestを送ってもらっています。(どちらもとても助かっています。)
これからtfが自由に書ける人間が増えれば増えるほど、SREへの依頼/SREによる実装のワンクションを挟まない分リードタイムを短くできる/SREの工数が他の改善に向けられます。
ですので、ここを加速するために具体的な課題に対するチュートリアルやWorkshopなどやっていけたらいいなと考えています。
3.brigecrewのCustom Policyを増やしていく(Policy as Code)
brigecrewではPolicyを新規で作成することができ、法律/コーポレート・ガバナンス/セキュリティなどの会社固有の事情をPolicy as Code化していくことができるため、独自ルールはどんどんこちらによせて漏れなくDelivery前に適応していきたいです。（taggingに必ずowner argumentは含めるetc）
We are hiring SREs!!
前述のように、まだまだ弊社のInfra Delivery Processには改善の余地がありますし、その他アプリケーションリリース基盤のリプレイス、アプリケーションチューニング、モニタリング/オンコール最適化、カオスインジェクションの導入、SLO/SLIの見直しなどなどやらねばならないことが無数に存在しています。
また、2017年に発足したSRE team当初から変わっていないMission/Key Resultの設定に関しても3年経ち抜本的に見直していく時期に来ており、共にSRE CultureをRebuildしていきたい方にも是非来ていただきたいです。
急激にグロースしていく日本最大のマッチングアプリのビジネス阻害要因を最小化し、手段を選ばず成長を加速させていきたいエンジニアの方、少しでも興味があればまずは気軽にお話ししましょう！！
カジュアル面談ご希望の方は、私のtwitterのDMかWantedlyの募集ページから是非お願いします！
明日はData Directorの奥村さんのデータ組織に関する記事になります。
それではみなさま、良いお年を！
