【レポート】クラウドの利用メリットを最大化するための組織体制とそれを支える基盤テクノロジーの紹介 #AWSSummit

こんにちは韓です。 幕張メッセで開催されている AWS Summit Tokyo 2019 のセッションレポートをお届けします。

セッションについて

登壇者：

• 株式会社リクルートライフスタイル ネットビジネス本部 SREユニット 横断インフラグループ クラウドアーキテクト 天野 祐嗣

リクルートライフスタイルでは、急激なビジネスの変化に対応するためにクラウド基盤SENTOをAWS上に構築。クラウドCoEチームが各サービスでのクラウド導入・移行支援をすると共に、基盤を進化させ続けています。ユーザーにクラウド利用権限を大きく移譲しつつ、インフラ変更時のセキュリティリスクをリアルタイムに検知するサーバレス監査システムを実現、”開発スピードとセキュリティのトレードオフ”を解決しています。それらを実現するまでの取り組みを紹介します。

背景

リクルートライフスタイルでは日常消費領域に関するB2Cサービスを展開しており、 そのサービスのためには高速な仮説検証が必要となってきている。

そのためには以下のサイクルを高速に回す必要がある。

仮説→（開発）→プロトタイプ→（私用）→フィードバック→（仮説修）→ 仮説...

ところがアプリ(dev)がインフラ(ops)にミスマッチが生じており高速にサイクルを回すことができないでいた。

• 開発側は開発を高速に回したい
• インフラ側は安全・安定な環境を維持したい

対応方針

開発からインフラに作業依頼を行うときに多くのコミュニケーションが必要となる。これがスピードを落とすボトルネックになっている。 開発の注文通りにインフラが作業することになるので二度手間になる。

そこで インフラから開発に権限を委譲 することとした。

一方、権限移譲をおこなうと、インフラ側でできる労力が増える。そこで インフラを進化させ開発を高速化させる ことに注力することを行うこととした。

また、環境はパブリッククラウド(AWS)とした。その理由は、 - 低コスト・高速 - マネージドサービスを利用することで車輪の再発明を防ぎ、価値ある部分の開発に集中することができる

これにより以下が実現できるようになる。

• 開発にアジリティを獲得できる
• インフラは 守 から 攻 へ転換できる

具体的な施策

リクルートライフスタイルの基盤 "SENTO"(遷都) といい、ミッション・ビジョン・バリューは

• ミッション・ビジョン・バリュー
  • 急激なビジネス変化に対応するためプロダクト開発運用のアジリティ向上
  • プロダクト開発者で完結
  • アプリに加えてインフラにも責任も持つ
  • 自由と責任
• ミッション
  • プロダクト開発者支援
  • 規範台ダンス、批判でなく助言的な
  • クラウド開発基盤・共通サービスの提供
  • →優れたプロダクトをユーザ・クライアントに提供し続ける

組織体制

• 組織が出来たときはクラウドに強い人は居ないため、プロダクト毎にクラウドに強い人を置くことは無理。
• 少ないクラウドアーキテクトでプロダクト開発者が自立してクラウドを活用できるように育成する
• 現時点では、メンバー:10、AWSアカウント数:60

プロダクト開発者支援

• ガイドライン策定、アーキテクチャ検討サポート、育成
• いざという時のトラブルシュートや、
• 気軽に相談できる環境
• 開発者の自立を促す

フェーズ毎の具体的な支援内容は下表の通り：

フェーズ	立ち上げ時	初期構築	リリース	運用
内容	キックオフ、ヒアリング	VPC,IAM,監視、セキュリティなどの標準構成の提供	QA対応、トラブルシュート	QA対応
関与	++++	+++	++	+

共通基盤

• セルフサービス型
• 開発者が使用したい機能を自由に使える
• 写真の再発名を防ぐ
• LDAP,メールGW,ID管理、コスト分析、ログ分析、OpenAM,SSHfumidai 、標準VPC、
• 共通リポジトリ：EOL情報とその対応策

基盤を運用していくにあたって大事にしていること

毎年AWSから新機能・サービスがリリースされている。新サービスのほうがより良いため、これに追従していく必要がある

具体的に行った施策は：

• VyOS → VPC peering
• ECS → Fargate

キーは「いかにEC2を減らすか？」にある。 時代と共に基盤も進化する必要がある

開発者が行う設定変更の監査システム

ここで「開発に権限委譲してセキュリティは大丈夫？」という疑問がでるはず。 アジリティとセキュリティ(※)はトレードオフなのが常であるが、リクルートライフスタイルではこれを両立している。それが Cloud Linebacker。

※ ここでいう「セキュリティ」のスコープは「クラウド上のリソースの設定」

監査機能(Cloud Linebacker)

目標とする機能は

開発者が時AWSアカウントに設定変更を行った際にアラートが挙がり、管理者から開発者にフィードバックができる

殆ど AWS Config で賄えるように思われるが自前で組んだシステム。その理由は：

• クラウドアーキテクト不足だった
• SENTOで監査し、修正までを担保する必要があり機能不足だった

しかし多くは AWS Config を使っている、監査部分は自前で作った

機能概要

• イベントドリブン＋バッチ
  • イベントドリブン
  • 開発者が自分のAWSアカウントのリソース変更時
  • AWS Config でイベント発火
  • 監査側のアカウントのLambdaが動きDynamoDBに情報格納し、SNSで Cloud Linebackerに通知
  • Cloud LineBackerで監査を実施し、適宜開発者にフィードバック
  • バッチ
  • AWS Config 未対応サービスは定期的に見に行く必要がある
  • 監査対象サービスを追加したとき(リソースが変更されるまでイベント発火しない)
  • Cloud LineBackerで監査を実施し、適宜開発者にフィードバック
• 監査機能・結果の集約
  • 複数プロダクトのアカウントから一つの CloudLinebuckerアカウントに集約される
  • 共通ルールで一般的な観点を網羅
  • アンチパタンだけでなく、バッドプラクティスもチェックする
  • 監査ルールの作り方
  • やりたいことから逆算：　守りたいこと　＞ チェックすることの順序
    • EC2インスタンスを社外から操作されないようにしたい ＞ SSHが社外IPから接続可能な状態になっていない
  • ルール毎に重要度を設定
• 監査機能・結果の集約
  • 一括表示できるモニタを作成
  • 監査結果の一覧
  • 監査結果の詳細表示、コメントも付与できる
  • ダッシュボードも実装
  • SENTOメンバが修正を（他メンバーが）アドバイスできる→育成
• 監査ルールのカスタマイズ
  • Python
  • カスタマイズが容易に、
  • プロダクト個別の要件にあった監査を実現
• サーバレス
  • トリガは AWS Config
  • Lambda + Dynamoで
  • Lambda > Dynamo > Lambda > Dynamo > Lambda と数珠繋ぎ

上記の施策により、開発効率の向上と運用負荷の軽減を得ることができた。

運用して分かったこと

• 1日あたり1000件の自動監査を実行
  • 手動ではありえないことを正確かつ短時間に出来ている
• ベストプラクティスの実現
  • バッドプラクティスの指摘もしている

サーバレスのフル活用で開発・運用の省力化し、監査することで品質が向上、 また開発者の自立を促すことができるようになった。

今後もプロダクト開発者支援は継続し、共通基盤の進化を通じて一層のクラウド化を推進していくつもりだ。

---

おわりに

登壇者の天野様はまだ新卒2年目ということですが、本稿に乗せた SENTO の開発を主導しているは素晴らしいと感じました。

また、現場の考えが「許可を求めるな、謝罪せよ。従え、心の声に。」とのことで、我々クラスメソッドAWS事業本部の考えと同じなのもシンパシーを感じますね。