星野リゾートにおけるインフラ内製化の試行錯誤について

星野リゾートにおける インフラ内製化の試行錯誤について 2024/7/16 星野リゾート 藤井崇介

2 お願い Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。

アジェンダ ⚫ イントロダクション ⚫ インフラ内製化開始 ⚫ コロナ禍の対応 ⚫ 現在の活動 3

4 イントロダクション

自己紹介 5 藤井 崇介 星野リゾート 情報システムグループ IPAアジャイルWG @ZooBonta ・SIerとして10年働いたのち、18年に中途採用で入社。 ・入社後は1人からエンジニア組織を立ち上げ、内製化を促進 ・現在は、社内の技術標準化チームを作り、複数プロジェクトの 支援を行う

会社紹介 • 全国約80施設のリゾート・温泉旅館・ホテルのオペレーションを 担っている総合リゾート運営会社 • 星のや・界・リゾナーレ・OMO・BEBの複数のサブブランドで運営 • 1914年創業、長野県軽井沢に最初の旅館を開業し、今年で110年 • 国内で運営特化戦略をいち早く取り入れ、世界に通用する運営会社 を目指している 6

組織紹介（情報システムグループ） プロダクト オーナー サービスチーム （現場） 出身者 31名 ソフトウェアエンジニア ITインフラ専任者 IT運用専任者 ビジネスコンサルタント エンジニア 企画 投資判断 運営 サポート インフラ 権限管理 プロジェク トオーナー Team ノーコード オペレーション インフラ 12名 20名 開発 4名 23名 ノーコード ツール 活用開発 7 リスク管理 予約システム 導入支援 環境構築 エンジニ ア Team 18名 改善 保守運用 ノーコード 開発 施設サイト

8 星野リゾートにおける インフラ内製化の試行錯誤について

AWS利用の歴史 9 ⚫ 導入期 ⚫ 事業の拡大につれて、システムの安定性が課題になる ⚫ スケールアップ・スケールアウトが求められる ⚫ 構築は外部パートナーに依頼 AWS利用開始

当時のシステム構成 10 ⚫ 基本構成 Classic Load Balancer フロントエンド Amazon RDS Amazon API Gateway Amazon S3 Amazon CloudFront Amazon EC2 その他 AWS Lambda など Amazon CloudWatch サーバーサイド Amazon Route 53

内製化の開始 11 ⚫ 外部に依存した開発体制からの脱却 ⚫ 仕様の認識齟齬から生まれる不具合やスケジュール遅延 ⚫ スケールアウトしづらい開発体制 ⚫ 社内の状況に合わせた開発 ■参考 創業105年の旅館運営企業が実現した毎週リリースするチームの作り方（Developers Summit 2020) https://www.docswell.com/s/s-fujii200/KJ18NZ-2022-06-20-143044

• https://www.docswell.com/s/s-fujii200/KJ18NZ-2022-06-20-143044

当時の体制 12 藤井 4～5人 チーム１ 4～5人 チーム２ 1人 インフラ

AWSを利用し始めた結果 13 良かった点 ➢システムの安定稼働 課題 ➢ガバナンスが効かない ➢インフラ準備期間の短縮 ➢セキュリティ ➢CI/CDの自動化 ➢コスト管理 ➢１人体制の限界 組織拡大において、ボトルネックになってきた

問題の原因 ⚫ 原因 ⚫ 管理体制がない ⚫ 横断して全体を見る人がいない ⚫ インフラエンジニアとその他のエンジニアとの分断 インフラエンジニアとともに、整理を開始 14

整理を開始 やったこと 15 やりきれなかったこと ➢リソースの一覧化 ➢既存のリソースの見直し ➢指針の作成 ➢料金の最適化 ➢レビュー体制の構築 ➢インフラメンバーの育成 ➢社内勉強会の実施 ➢Terraformでの管理 約2年かけて、ようやく道筋が決められた

16 ようやく内製化の 道筋が見えてきた

コロナ発生で大きく変わる 生き残るためにコストカットが 最優先事項となる 17

コストカット対策 1. 2. 3. 18 サーバの起動時間見直し サーバを利用していない時間にはインスタンスを起動しないようにした 不要なデータの削除 AMIやS3などに不要なデータが大量に溜まっていたので、削除した インスタンスタイプの見直し T2系やM4系などの、古いインスタンスタイプをすべて置き換えた 約13% コスト削減 さらなる改善のために協力を要請

コストカット対策 4. 19 適切な契約によるコスト削減 当初、一律5%引きのプランで契約していたが、Amazon EC2やCloudFront を使っている環境では、もっと良い契約があった。

コストカット対策 4. 5. 20 リザーブドインスタンス購入 本番環境など、常時起動しているEC2やRDSについては、リザーブドイン スタンスを購入することで、大きくコストが削減できる。 対象 契約数 Amazon EC2 78台 Amazon RDS 18台 その他 サーバの使用状況から、適切なインスタンスタイプを選択

コストカット対策 21 約29% コスト削減

コロナ禍での開発 22 温泉IoT 湯守 GoToキャンペーン対応 6週間でリリース 1ヶ月でリリース 結婚式新サービス ふるさと納税 1ヶ月でリリース 3ヶ月でリリース

23 内製化のおかげで 変化に対応できた

24 現在の活動

活動内容 25 ⚫ AWS CDKによるインフラ管理 ⚫ コードでインフラを管理することで、不明な設定が入ることがなく なった ⚫ アプリケーションエンジニアにはTerraformよりも馴染めた ⚫ 共通のfunctionを作ることで、再利用性が向上した

活動内容 ⚫ Security Hubの導入 ⚫ AWS のセキュリティ状態を包括的に把 握し、ベストプラクティスに照らして 環境をチェックできるサービス ⚫ 危険な設定やトラブルを未然に含む設 定をチェックできる ⚫ 対応の有無に困ったときは、クラス メソッドのガイドブックを参照。 26

活動内容 27 ⚫ インフラの標準化活動 ➢基本のインフラの標準構成を統一 ➢セキュリティ ➢サーバ：ECS(Fargate) ➢WAFの設定 ➢データベース：PostgreSQL ➢パスワード管理ポリシー ➢Queue：Amazon MQ(Rabbit MQ) ➢Security Group設定ポリシー ➢CI/CDの仕組みを統一 ➢GithubActionsのテンプレート統一 ➢デプロイ時のテスト実行 ➢開発用ドキュメント生成 ➢認証・認可 ➢アプリケーショントークンの管理方法 ➢運用監視 ➢ログ管理(DataDog + S3) ➢OpenAPI公開 ➢リソースダッシュボード ➢テーブル定義書作成 ➢アラート通知 ➢ドメイン図（JIG）作成

活動内容 ⚫ ディレクトリ構成 └── sample ├── main ├── README.md │ ├── firelens_container.md ├── cdk.json ├── bin │ ├── <project> ├── main-common │ └── secure.ts │ │ ├── bin │ ├── bin ├── cdk.json │ │ ├── fluentbit │ │ └── main-common.ts ├── common │ │ ├── lib │ ├── lib │ └── lib │ │ ├── cloudfront-functions │ │ ├── test.json │ ├─ s3.ts │ │ └── types │ │ ├── cloudfront-functions-stack.ts │ ├─ backend.ts │ │ ├── cognito-stack.ts │ └─ ecs-service.ts │ ├── test.json │ │ ├── ecr-repositories-stack.ts ├── fluentbit │ ├── prod.json │ │ ├── ecs-cluster-stack.ts ├── test.json │ └── types │ │ ├── ip-restriction-stack.ts ├── prod.json │ └── main-common-context.ts │ │ ├── lambda └── types ├── lib │ │ ├── log-buckets-stack.ts └── secure-context.ts │ ├── constants.ts │ │ ├── mq-stack.ts │ ├── context-reader.ts │ │ ├── rds-stack.ts │ ├── ecs-firelens-function.ts │ │ ├── route53-stack.ts │ ├── ecs-service-construct.ts │ │ ├── slack-notify-stack.ts │ │ ├── vpc-lattice-network-stack.ts │ └── types │ └── common-context.ts │ │ └── waf-stack.ts 28

活動内容 29 ⚫ ディレクトリ構成 ├── cdk.json ├── main-common │ ├── bin │ │ └── main-common.ts │ ├── lib │ │ ├── cloudfront-functions │ │ ├── cloudfront-functions-stack.ts │ │ ├── cognito-stack.ts │ │ ├── ecr-repositories-stack.ts │ │ ├── ecs-cluster-stack.ts │ │ ├── ip-restriction-stack.ts │ │ ├── lambda │ │ ├── log-buckets-stack.ts │ │ ├── mq-stack.ts │ │ ├── rds-stack.ts │ │ ├── route53-stack.ts │ │ ├── slack-notify-stack.ts │ │ ├── vpc-lattice-network-stack.ts │ │ └── waf-stack.ts アプリと独立して作成するリソース ECSサービスの作成（≒デプロイ）はECSクラスターやECRが存在し ている必要があり、アプリのcdkプロジェクトではECSサービスの設 定やタスク定義だけを意識したい DBはリストア時などを考慮し、アプリと分離して構築 FQDNの命名規則を最低限守るために共用するホストゾーンを作 成してアプリごとにゾーン委任してもらう凡例： {ProjectName}.{EnvName}.{ApexDomain} CI/CDを標準化する一環として、デプロイ通知の仕組み (EventBridgeやAWS Chatbot)も同じ仕組みで構築する WAF ACLは共通・顧客向け・社内向けの3つを作成して、一部のル ールは共用している

活動内容 30 ⚫ ディレクトリ構成 │ ├── test.json │ ├── prod.json │ └── types │ └── main-common-context.ts ├── lib │ ├── constants.ts │ ├── context-reader.ts │ ├── ecs-firelens-function.ts │ ├── ecs-service-construct.ts │ └── types │ └── common-context.ts 複数のStack間で受け渡しするSSMパラメータの名前の管理 各アプリで利用する共通的な関数を共通ライブラリとして提供 共通処理 標準的な構成とサンプルを提供 社内共通で使えるように整備中 アプリ個別処理 └── sample ├── README.md ├── bin │ └── sample.ts ├── cdk.json ├── lib │ ├─ s3.ts │ ├─ backend.ts │ └─ ecs-service.ts ├── fluentbit ├── test.json ├── prod.json └── types └── secure-context.ts

内製化で気を付けたこと ⚫ 小さくできることから始める ⚫ 専門家に頼りながら、自分たちで手を動かす ⚫ 一緒に進めてくれる仲間を増やす ⚫ 成果を周りにアピールする 31

33 ありがとうございました https://hoshinoresorts.com/jp/ インフラエンジニアも募集中です！ https://www.wantedly.com/projects/1722802

• https://www.hoshinoresorts.com/
• https://www.wantedly.com/projects/1722802