ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

【セッションレポート】AWS Summit Tokyo 2023 NTTデータが8年間一緒に歩んだリクルート様のAWS共通基盤での挑戦の軌跡

こんにちは、AWSチームの大澤です。

今回は、AWS Summit Tokyo 2023のセッションとして、NTTデータ様・リクルート様のセッションに参加しました。

そちらの様子をレポートします。

セッション概要

セッション番号:[AP-09]

開催日時:2023/04/20 (木) 16:20-17:00

タイトル:NTTデータが8年間一緒に歩んだリクルート様のAWS共通基盤での挑戦の軌跡

カテゴリー:パートナーセッション

場所:ホール7 Room J

当社が長年に渡って支援させて頂いているリクルート様は 2011 年からアマゾン ウェブ サービス(AWS)の本格活用を開始しました。10 年を超えて AWS を活用した世界がどのようになっているのか、想像できない方も多いのではないでしょうか?リクルート様では、クラウド活用が進むにつれて、社内共通機能として提供していた認証機能やネットワーク、セキュリティ基盤などの運用で課題が浮き彫りになってきました。本セッションでは、そうした様々な課題をリクルート様と NTTデータが協力しながら解決していった事例をご紹介します。またリクルート様での『エンタープライズ SRE』実践の一端もご紹介いただきます。

Speaker

  • 奥村 康晃 氏 (株式会社NTTデータ)
  • 宮崎 幸恵 氏 (株式会社リクルート)

レポート

NTTデータ様セクション

NTTデータから見たリクルート様

  • 会社の壁を超えた良き相談相手でありたいという気持ちで一緒に取り組んでいる

    • 懐の深さ
      • 様々なチャレンジを受け入れてくれる
    • 当事者意識
      • すべてを自分ごと化

NTTデータのSRE as a Service - サービス概要 -

  • 開発と運用の両面からお客様のSREチームをご支援

  • クラウドネイティブ環境でのDevOpsを熟知したエンジニア (SREチーム)による業務支援

    • 開発支援系のサービス

      • システムアーキテクチャ検討
      • PoC
      • 開発ガイドライン作成支援
      • PMQ/QA支援
    • 運用支援系のサービス

      • アップデート対応支援
      • コスト可視化/最適化支援
      • セキュリティガード/レース実装/運用支援

リクルート様セクション

ID/認証とアカウント設計は最重要

  • 権限制御がしやすい
    • AWSリソースごとの権限制御は複雑化するため、1アカウントずつ用途は分けたほうがシンプル
  • サービスへの影響を最小化
    • アカウント単位で機能を分けて設計をすることで、サービスへの影響や意図しないリスクを最小化可能
  • アカウント間の連携は様々なマネージドサービスがあるため、あまり障壁にはならなかった
  • 同一アカウントで様々な機能を含めてしまい複雑性が増すことの方が、デメリット

EOLはシステム設計再考の機会

  • リクルートではこの10年で様々なシステム公開を実施
  • きっかけはマネージドサービスのGAのタイミングや、導入しているソフトウェアのEOLなどのタイミングがある
  • 社内的にも更改理由の説明がしやすい
  • 過去の負を解消し、より良いシステムに変えられる機会

AWS Security Hubを用いた監査/リスク検知システム

  • 共通のSecurity Hubの情報を集約するアカウントを用意・全サービスアカウントの情報を収集
  • マネージドルールは全社共通のルールを設定し、検知した内容は社内のセキュリティ部署と連携し是正

フェーズ単位でのクラウドの利用推移について

  • 黎明期: クラウド利用の浸透のためにアーリーアダプターなグループと協力
    • 積極的に採用してもらえるグループにクラウドを試してもらう
  • 急増期: 運用課題解決、ユーザ要望対応で様々な新しい取り組みを模索
  • 安定期: 黎明期や急増機に作成したシステムの更改、定形化による作業工数削減

システムに必要な期待値のコントロール

  • 認証基盤やセキュリティ機能については、重要度が高いため、耐障害性を考慮した構成を取る

    • AZ複数の冗長化
    • オートスケールによる自動復旧の仕組み
    • 設定ファイルはNFSに配置
    • バックアップは日次で自動取得
  • サービスに直接的には影響しない、監査システムについては、数日間動いていなくても問題ないと判断し、厳密にはしていない

  • システムに求められる要件は都度確認し、見直す

まとめ

長くAWSを運用するには

  • アカウント管理/ID管理は基本的にベストプラクティスを参考する
    • 機能ごとにアカウント分離はしたほうが後々拡張性が高まる
    • 複雑化しそうな要素はできる限り避ける努力は必要
  • 定期的なシステム見直し/更改のタイミングを逃さない
  • クラウド利用システムの期待値を正しく調整し、できること・できないことを認識は合わせておく

所感

  • AWSアカウント管理の数が膨大になったり・管理が複雑化してしまう背景を知ることができました

  • 長くAWSを管理するためのポイントとして、機能ごとにAWSアカウントを分ける・ベストプラクティスを参考に設計すること・システムの更改タイミングを逃さないといったことを意識することの重要性について理解が深まりました。

  • 数多くのAWSアカウントを管理する中で、各アカウントのセキュリティの状態は一元的把握できるような設計がないと、検知が難しくなる側面もあるということがわかりました。