「進化し続けるインフラ」でありたい　リクルートのAWS基盤チームによるマルチアカウント管理

クラウドの恩恵をプロダクトに届けることをミッションに

須藤悠氏（以下、須藤）：では『「進化し続けるインフラ」のためのマルチアカウント管理』について発表いたします。私、須藤と申しまして、好きなAWSのサービスはFargateとOrganizationsです。ただOrganizationsは使い倒すっていうほど使いこなせてはいない状況です。

HashiCorpのプロダクトが好きでして、TerraformとかTerraform Enterpriseがとても好きです。あと猫とかピザが好きで、猫とピザの、（着ているTシャツを指し）このおもしろTシャツを着てたりします。

所属はリクルートのライフスタイル・SaaS SREグループやリクルートライフスタイルのSREグループというところにいます。リクルートのライフスタイル領域あるいは日常消費領域と言われているプロダクトを扱うところです。

ホットペッパーグルメとかホットペッパービューティー、あるいはじゃらんnetといったサイトにお世話になったという人はけっこう多いんじゃないかと思います。そうしたライフスタイル領域のためのAWS基盤チームにいます。

どんな基盤なのかと言いますと、チームとしては13人おりまして、約90アカウントのAWSアカウントを管理しています。この90アカウントに対して横断的な管理とかコスト配賦、それから共通機能の提供・運用・進化。AWS利用者に対するCCoE活動とか、リアルタイム監査をやっています。

我々の基盤は2016年からスタートして、発足5年目です。スタート時は数アカウントでした。進化し続けるインフラのチームということでずっとやってきておりまして、クラウドの恩恵をプロダクトに届けることをミッションに活動しています。

基盤チームの役割とTerraformの導入

我々基盤チームの役割を簡単に紹介します。プロダクト側からAWSアカウントがほしい、AWSを使いたいという申し出がありますと、我々がヒアリングあるいはアーキテクチャレビューをします。そのうえで標準構成済みのアカウントをプロダクトに引き渡します。

プロダクト側は各AWSサービスを利用します。その中でなにか問題があったり監査に引っかかることがありますと、継続的なCCoE活動とかリアルタイム監査のフィードバックといったアクションをこちらから起こします。それに対してプロダクト側に問題対処してもらうといったようなかたちになっています。

この標準構成済みアカウントを作るために我々はTerraformを使っています。約90アカウントすべてのアカウントに運用しています。Terraform Enterpriseで管理しており、プルリクエストを作成したら自動でプランが走るようになっています。

また作成されたプランに対するアプライは管理者がチェックをして実行という、承認のフローが挟まるようなかたちで運用しています。

Terraformの運用に至るまでにけっこう苦労した歴史がありまして、最初は手動で構築していました。その後1年程度はCloud Formationによる構築、さらにその後2年程度かけて次第にTerraform化していきまして、現在はTerraform Enterpriseで運用しているといった状況になります。

最初にCloud Formationを採用した動機はInfrastructure as Codeをしたかったからなのですが、当時あまりCloud Formationのサービスアップデートがされておらず、また手動で構築した部分に対してインポートすれば構築済みのリソースも管理できるTerraformというのは魅力がありました。そういったことから、Terraform化をしていったという歴史があります。

Terraform Enterpriseを導入した背景としては、自前でCI/CDの維持管理をすることや、強力なCredentioalの運用に限界を感じていたからです。90アカウント分のCI/CDとかCredentioalの管理となると、相当大変そうだなっていう印象を持ってもらえるかと思います。Terraform Enterpriseで運用するようになってから月間1,000プラン200アプライぐらいの運用が実現するようになっています。

Terraform Enterpriseの導入に関しては、以前私がテックブログに掲載した記事がありまして、その中で2019年ミートアップで発表した資料も紹介しています。（スライドを示し）興味のある方は、こちらのURLか、あとはTerraform Enterpriseで検索すると2番目ぐらいに出てくるので、それで見ていただけるとおもしろいかなと思います。

4つに分けた基盤の権限構成

今回はAWSのミートアップですので、どのAWSの機能を使っているかについても紹介していきます。マルチアカウント管理で利用しているAWSの機能の前に、まず基盤の権限構成の話をさせてください（笑）。この話をしないとちょっと通じない部分も出てきます。

我々の基盤の権限構成は4つに分かれています。最初からこうだったわけではなくて何度も調整して今のかたちに落ち着いています。1つは管理者権限、1つは開発者権限、1つは運用者権限、1つはコンテンツ権限です。

管理者権限はプロダクトの責任者向けで、SCPやS3のバケットポリシーでDenyされていること以外はほとんどなんでもできるような権限を持っています。開発者権限は開発者一般向けで、いくつかのサービスに対してDenyがかかっておりまして。IAMの作成とか変更、ビリング、RIとかSavings Plansの購入、Config、CloudTrail、VPC、DX、VPNといったものがDeny対象になっています。

運用者は開発者のDeny対象に加えてSubnetとかSecurityGroup、Spot Instance、RouteTable、NetworkACLといったものをDenyしています。これはEC2内部の運用を主にする人向けの権限のためです。コンテンツ権限についてはS3バケットを更新する用の権限となっています。

root権限はかなり厳重に制限をしておりまして、我々基盤チームでMFA管理をしています。特定のMFAデバイスがないと利用できないというかたちですね。それからrootが必須な時以外使わないということをしています。そもそも使うのが面倒なので、rootが必須な時以外は使いたくないっていうのもあるのですが（笑）。

root権限はサポートプランの変更ですとかAWSのサービスのオプトインが必要な時に利用しています。このroot権限のプロダクト側の利用は不可としていて、基盤側に作業依頼を出してもらうといった管理になっています。

マルチアカウント管理で利用しているAWSの機能

改めまして、マルチアカウント管理で利用しているAWSの機能をざざっと紹介していきます。まずは、CloudTrailとConfigです。このあたりマルチアカウントで使っていないというケースはかなり減ってきているんじゃないかなと思います。

Trailログの出力先のS3バケットは基盤チームで利用するTerraformとrootを除くあらゆるユーザーが変更・削除できないようバケットポリシーで制限しています。ただGet系のアクションは制限していないため、Athena等で調査目的の読み取りは可能となっています。また内製のリアルタイム自動監査システムがありまして、これでCloudTrailとConfigの出力を利用しています。

次はGuardDutyです。GuardDutyはなにか異常を検知したら教えてくれるというサービスです。これによって検知があればSNS Topicを通じてメールとSlackで通知するように設定しています。ただ内製のリアルタイム自動監査システムとCCoE活動が実を結んでか、GuardDutyに検知されるような事象はあまり起きていないです。

次にVPC PeeringとTransit Gatewayですね。VPC Peeringは基盤アカウントと各アカウントを接続するために使っています。基盤アカウントで踏み台とかLDAPによるID管理とかDirectConnectによる専用線接続といったものを提供しているためです。

また多数のSite-to-Site VPN接続を抱える部分についてはTransit Gatewayを利用しています。VPC PeeringをTransit Gatewayで置き換えないのかって疑問に思う方もいると思うのですが、移行コストも含めて考えるとちょっとROI悪いねっていうことで。そちらのほうにはまだ舵を切っていないっていうかたちになります。

ちなみに2020年に行われたAWS Summit Onlineなんですが、別の基盤チームがTransit Gatewayのセッションを持っていますので、Transit Gatewayが好きな方はぜひご覧になってください。

次にOrganizationsのSCPですね。Service Control Policyです。これはOrganizationsのLeaveOrganizationみたいな操作を封じたいアクションをDenyしています。まだ適応まで至っていないんですが、基盤管理のTerraformで構成したリソースのうち勝手に変更されると困るようなものもDenyする準備をしています。

コストに関しても取りまとめる

次にCompute SavingsPlansですね。これはコミットメントを設定するとその範囲で割引を受けられるサービスです。親アカウントでコミットメントを設定して、全アカウントで割引の恩恵を受けています。Fargateの利用料が高くて、その部分に恩恵を受けたいアカウントがある場合には個別にそのアカウントでSavingsPlansのコミットメントを設定するということもできます。

どうしてこういうことをするかと言うと、Fargateの割引率って相対的に低く、割引が適用されにくいという背景があります。RIの購入については個別アカウントでのみやっていて、親アカウントでの購入はしていません。

Consolidated BillingとCost Explorerはコストに関して取りまとめる時に利用しています。Invoiceの金額、請求書ですね。あとGetCostAndUsage APIっていうのがCost Explorerにあるんですが、これを利用して毎月Pythonスクリプトでどのアカウントにいくら配布するかを算出しています。

親アカウントで購入しているSavingsPlansのコストも各アカウントで適用された割引額に合わせて配布しています。これらの配布額については各アカウントの管理者に金額をお知らせするんですが、そのメールはGoogle App Scriptで一斉送信ということをやっています。

マルチアカウントでRDSって出てくると、ちょっと変な気がする方が多いと思うんですが。意図せぬDB再起動によりサービス障害を発生させないために、全アカウントに対して RDSのDescribePendingMaintenanceActionsを発行して、見過ごされているメンテナンススケジュールがないか定期的にチェックしてSlack通知しています。これ実装はCloudWatch EventsとLambdaとSTS AssumeRoleを利用しています。

あとRoute53とDynamoDBですね。これは各アカウントの内部HostedZoneレコードをDynamoDBに集約して基盤アカウントにも登録するために使っています。共用踏み台から各アカウントのインスタンスにSSHする場合、ホスト名でもアクセスしたいよねっていうことでこういうのも準備しています。これも実装はCloudWatch EventsとLambdaとSTS AssumeRoleになっています。

Certificate ManagerとRoute53、これは開発用エンドポイントの証明書とサブドメインを移管するために使っています。開発用であっても正しくHTTPSを使うということを根付かせるためですね。これはクロスアカウントでの操作が必要になるためにTerraform化していません。

今からマルチアカウント基盤を作る人はマネージドサービス活用を第一に考えてほしい

Terraform化しているしていないの話だと、Terraform化の範囲は？っていうのがやっぱり気になると思います。このへんをTerraformで構築していますよっていうのをまとめてきました。

基本的にはそのアカウントで必ず作るであろうものは最初にTerraformで構築して渡すということをやっています。それからIAM関連で必ず作っとくよね、あるいはないと困るよねっていうものもTerraformで構築しています。

ここまで話をしても、まあほかにも必要なものあるよねってなりますね。マルチアカウント管理のために独自に作り込んでいる仕組みもあります。LDAPによるID管理とフェデレーションの部分ですね。

我々の基盤ではLDAPにアカウントを登録することでSSHとかマネジメントコンソールが使えるようになります。IDプロバイダーとしてはOpenAMを使用しているんですが、これもFargate上で動作するKeycloakに移行する予定です。

利用者からアカウント払い出し時に公開鍵を受け取って、自動でMFAトークンをメール通知しています。マネジメントコンソールへのログインはOpenAM経由フェデレーションログイン、つまり個別のユーザーはIAMユーザーを持ちません。OpenAMにログインする時にMFAが必須になります。SSHをする時も同様にMFAが必須になります。

LDAPの直接操作はさすがにしんどいのでWebアプリのID管理ツールを作って提供しています。これはRailsで作っていますが、これもちょっと古くなっているので書き換えようとしています。

ID管理とフェデレーションの部分についてなんですが、今からマルチアカウント基盤を作る人は同じやり方をしてほしくないなと思っています。マネージドサービス活用を第一に考えてほしいです。AWS SSO、AWS Directory Service、AWS Systems Managerといったかなり便利なサービスがあるのでこのへんを活用してください。

権限構成については熟慮して改善を続けてほしいです。弱すぎる権限だと生産性が大きく低下しますし、強すぎる権限だと事故の影響範囲が大きくなります。独自のID管理を選択するのは相当な覚悟が必要だなと思っていて、我々もLDAPはやめたいがやめられない状態になっています。SSMのSession Manager化したいなぁっていうのは思いとしてあります。

先ほどから出てきているリアルタイム自動監査システムは、Cloud Linebackerと呼んでいるものなんですが、これについては2019年のAWS Summit 2019で我々のチームの天野が発表したものがございますので、興味がある方はご覧になってください。

インフラ運用だけじゃない介在価値を出したい

最後にマルチアカウント管理で大切にしていることについてお話しします。タイトルにもしていますが、進化し続けるインフラであることですね。基盤チームがいることでプロダクトを幸せにできるか。インフラ運用だけじゃない介在価値を出したいということを思っています。プロダクトに寄り添い伴走し、成長させるといったようなインフラチームでありたいなと思っています。

AWSを使っていますので新機能とか新サービスのキャッチアップも大切にしていて、この機能はどこに適用できるか？　このサービスはどこに活用できるか？　移行する場合のROIはどうか？　といったことは常に考えています。また各サービスの特性を理解して冗長性とか可用性とかガバナンスをどう担保していくかといったところをかなり注力して活動しています。

最後に障害を学びにする。障害ってどうしても起きちゃうので起こさないように努力することが大事なんですが、トラブルシュートってかなり学びの宝庫なので、どうしても起きちゃった障害に関してはそれを学びにするっていうことをやっています。

我々も一緒に働く仲間を探しています。興味のある方はぜひご覧になってください。ありがとうございました。須藤の発表は以上です。

基盤チームの教育は壁打ち相手を作って進める

光野達朗氏（以下、光野）：須藤さんありがとうございました。それではここからはSlidoでいただいた質問を見ていきましょう。お時間の都合なのですべてお答えできないことを予めご了承ください。

ではちょうど最初にいただいた質問、「アーキテクチャレビューできるには幅広いAWSスキルが必要になると思いますが、そのために基盤チームのメンバーの教育は何かやっているのでしょうか？」。こちらいかがでしょう？

須藤：基盤チーム、メンバーごとに得意分野とあまり得意でない分野が必ずあると思います。基本的には1つの機能の適用とか検証といったものは1人でやってもらっているんですが。そのときにレビュアーとしてよりハイスキルな人、あるいはそのサービスに対して知見を持っている人っていうのを付けて、1人で進めるのではなくて壁打ち相手を作って進めるといったようなことをやっています。

光野：ありがとうございます。それでは次の質問に移りたいと思います。「CloudFormationからTerraformへの移行を決めた際にCloudFormationではつらいなと感じたポイントをいくつか教えていただきたいです」。こちらいかがでしょうか？

須藤：当時の話で恐縮なんですが、当時まだCloudFormationでYAMLが使えるようになっていなかったと記憶していて、JSONを書かなきゃいけなかったんですね。JSONを書くのがつらいっていう純粋な部分と、あとは発表の中でもちょっと触れましたがTerraformだとすでに構築しているリソースをインポートしてInfrastructure as Codeの中に組み込むことができるという、その2点が大きな判断ポイントになったかなと思っています。

光野：ありがとうございます。確かにJSONしかなかった時代がありましたよね。非常につらい時代だったと思います（笑）。それではもう2つほど質問を選んでいきたいと思います。では少し長いのですがちょっと読み上げたいと思います。

社内のノウハウ共有とモチベーション維持の秘訣

「CCoEチームにいます。当初はCCoEチームがAWS全般に詳しかったのですが、複数案件を経るとプロダクトチームのほうにノウハウが蓄積するようになり、相談されても答えられないものが増えつつあるのが悩みです。社内のAWSノウハウの共有のいい方法と、CCoEのチームメンバーとしてモチベーション維持などあればなにかお聞かせください」。こちらいかがでしょうか？

須藤：ノウハウ共有の方法とモチベーションの維持ですか。けっこう難しいお題ですね。前半の内容に関しては、プロダクトチームがAWSに関して成長して成熟しているということなので素直に喜んでいいのかなと思います。それに対してCCoEチームが今まで関与してきたから成長させられたんだよって言える状態なら、それは誇っていい成果なんじゃないですかね。

その上で社内のノウハウ共有に関しては、AWSに対してとか特定の技術に対してモチベーションを持った特定の人が何人かいると思うんですね。そういう人に声をかけて勉強会のようなかたちとか、そこまで格式張ったかたちじゃなくてもうちょっとカジュアルなものでも、例えばオンライン飲み会しながら技術の話をしてみようみたいなところからでもいいですし、そういうことをやってみたらいいのかなぁと思いました。

モチベーションの維持に関しては、プロダクトのチームとCCoEのチームで注目すべきAWSのサービスっていうのが必ずしも一緒じゃないと思うんですよね。基盤に対して責任を持ったり、あるいはプロダクトチームが意識しないところでよりよくしていくっていう要素が入ってくると思うので。そういったところでなにか興味を持てるものを見つけて突き進んで行くっていうのがいいんじゃないかなぁと思いました。以上です。

光野：須藤さんありがとうございます。それではちょうどお時間になりましたので、以上でこのパートを終了いたします。ありがとうございました。