AWSインフラ⼀⼤刷新 〜幸せな運⽤を⽬指して〜 株式会社アカツキ サーバーエンジニア 守屋邦昭 

⾃⼰紹介 守屋邦昭 • 株式会社アカツキに新卒で⼊社して3年⽬ • 既存ゲームタイトルのアプリ・インフラ開発を担当 • 新規タイトルのインフラ構築を⼿伝ったりも • 趣味はポケモン、ギター、カラオケ、お笑い動画漁り 

はじめに 私の所属するチームでは AWS EC2 上でサーバーサイドの運⽤を⾏ってきました。 サービスリリース当初からの様々な改善の積み重ねの結果、近頃はインフラ障害も減って安定した運 ⽤が実現しています。 しかし既存インフラには様々な技術的負債が蓄積されており、メンテナンスし⾟い環境でした。 本セッションでは既存インフラを設計から⾒直して⼀⼤刷新し、技術的負債の解消を実現した経緯に ついてご説明します。 

アジェンダ • 移⾏前のインフラ構成と課題 • 具体的なアーキテクチャ刷新⽅針 • 本番環境移⾏への道のり • 移⾏の結果とまとめ 

移⾏の流れ 移⾏前のインフラ構成と課題 

Public subnet 移⾏前のインフラ構成 AWS Cloud Mobile client ElastiCache Memcached Redis S3 Deploy Cloud Front VPC Operator Public subnet Classic Load Balancer EC2 EC2 Private subnet Game API Auto Scaling group Private subnet Master User Log RDS Private subnet Private subnet Log-aggregator EC2 Admin 運⽤中モバイルゲームのサーバサイド 

アプリケーションサーバーの構成 EC2 上に構築されたサーバーサイドアプリ • Ruby on Rails + Nginx を⽤いたゲーム API サーバー • 管理者⽤ツール(Active Admin)やバッチ処理など複数の サービスが存在 • 構成管理ツール Chef でミドルウェアのインストール等の セットアップを⾃動化 EC2 Dotenv APIサーバー バッチ処理 ランキング集計等のバッチ処理 管理者⽤ツール アプリケーションサーバーの設定が複雑 

運⽤体制 Game API Admin RDS Master & User Hubot Migration Deploy Hubot command Slack からコマンドを叩くことで各種タスクを実⾏ • デプロイ(Capistrano3)や DB Migration は Admin(踏み台)サー バーから実⾏ • マスタデータの Seeding や検証⽤ダミーデータ⽣成など 運⽤・QA向けに多くのタスク (ほとんどが Rake タスク)が存在 • Slack から Hubot のコマンドを叩くことで⾮エンジニアでも 各種タスクの実⾏が可能 Adminサーバーを中⼼とした運⽤体制 

移⾏前インフラの問題点 • 環境毎に Chef の node ファイルで設定を管理しているが、普段は使わないので錆びついていく • クレデンシャル・環境変数が dotenv ファイルに記述されて全サーバーに直置き アプリケーションサーバーの設定が複雑 ⼿動で構築されたインフラ& 複数の開発環境が存在 • インフラ全体の設定の属⼈化が進⾏ • ゲームの新機能開発では複数のバージョンを並⾏で開発するため、開発環境が複数存在 新規環境の構築や既存環境の設定更新に⾮常に⼿間がかかる → Chef のレシピや dotenv ファイルを別途メンテナンスしていかなければならない → 新規環境の構築や既存環境の設定変更も⼿動で⾏う必要がある 

アーキテクチャ刷新で実現したいこと インフラ全体のコード管理とシンプルな構成管理の実現 環境間の差分をできる限りなくす 現場への負担を最⼩限に移⾏ 

移⾏の流れ 具体的なアーキテクチャ刷新⽅針 

Docker・ECS への移⾏ • Rails, Nginx, Fluentd 等のアプリケーションを全て Docker コンテナ上で運⽤ • ECS でコンテナの実⾏ & 管理を実現 • DB はコンテナ化するメリットがあまりない為、従来通りとする • ENTRYPOINT にスクリプトを挟んで条件分岐させることで、同じ Docker イメージ から異なるサービスを起動させる Application Server API Server Fluentd Admin Tool Batch サーバー⾃体の構成管理コストが激減 API Server Admin Tool Batch entrypoint.sh 

CloudFormationでインフラ全体を再構築 • VPC から全て作り直すことで AWS 上の全リソースをコード管理下に置く • Kumogata2 を導⼊すると Ruby で柔軟な設定の記述が可能となる • ホスト名等の環境毎に異なる情報は環境変数として envfile に記述 • サーバー上ではできるだけ Docker イメージを使⽤し、Ansible で最低限の構成管理 envfile を追加 CloudFormation 適⽤ リソース⽣成 新規環境の構築がコマンドで可能に • Adminサーバーのセットアップ • ユーザー管理 • カーネルパラメータ設定 etc... 

AWS Systems Manager Parameter Store を導⼊ • Gitの管理下に置けないクレデンシャルを AWS 上に登録 • API 経由でセキュアにパラメータを取得できる • Docker イメージにはクレデンシャルを埋め込まず、ECS デプロイ時にパラメータを取得 Systems Manager Parameter Store パラメータ 取得⽅法 全環境共通のパラメータ ECS タスク定義にて取得するパラ メータを指定 環境毎に異なるパラメータ Docker コンテナ起動時に API 経由で 環境変数に展開 環境毎にdotenvファイルを管理する必要がなくなる 

環境間の差分をできる限りなくす 開発環境の構成は CloudFormation テンプレートで共通化 STAGING 環境で動作検証した Docker イメージを本番でも使う • 環境毎のインフラ設定の差異は基本的に環境名のみ • RDS & Elasticache ホスト名等はすべて環境名に対応したDNSを付与 → DB 接続設定等の Rails ⽤ config ファイルもテンプレート化できる • Docker イメージのタグを付け替えて本番デプロイ • Docker build のタイミングによって依存するミドルウェアの挙動が変わることがある為 特定環境のみで再現する不具合をインフラレイヤーで防ぐ 

現場への負担を最⼩限に移⾏ • Admin サーバーは従来通り EC2 で設置し、Hubot コマンドも従来通り利⽤できるようにする • 各種 Rake タスクは Admin サーバー上でビルドした Docker イメージを使⽤して実⾏ (Adminサーバー⾃体に Rails 環境構築をする必要はない) 移⾏後も従来通りの運⽤が実現 ECR Game API Admin RDS Master & User Hubot Migration Deploy Hubot command Push 

新インフラ構成 Public subnet AWS Cloud Mobile client S3 Cloud Front CloudFormation VPC Operator Public subnet Application Load Balancer EC2 ECS Private subnet Game API Auto Scaling group Private subnet Log-aggregator ECS Admin Create stack ECR Push Deploy Auto Scaling group SSM Get parameters ElastiCache Memcached Redis Private subnet Master User Log RDS Private subnet 

移⾏の流れ 本番環境移⾏への道のり 

移⾏スケジュール 2018 2019 11 12 1 2 3 4 5 6 7 8 9 10 開発 本番適⽤準備 負荷試験 開発環境移⾏ メンテ 

本番環境の移⾏⼿順 • アプリのバージョンアップメンテナンス時に実⾏ • 開発環境同様にネットワークから CloudFormation で再構築 • 基本的な⼿順は CloudFormation でリソース作成 → デプロイ → DNS切り替え → 旧環境の停⽌ • S3アセットは新 bucket へ s3 sync でコピー しかし、データベースの移⾏が課題 データベース ⽤途 消してもOK? Master, User, Log DB (RDS) ゲーム内のマスタデータ、 ユーザデータ、ログ NG Redis(Elasticache) ユーザー毎のインゲーム出撃 データの⼀時保存など NG Memcached(Elasticache) ゲーム内マスタデータの キャッシュなど Cache再⽣成コマ ンドがあるので OK 

本番環境の移⾏⼿順 • Master, User, Log DB (RDS) • Redis(Elasticache) 膨⼤なデータの移⾏は⼤変なので、旧インスタンスを CloudFormation で作成した VPC に移⾏ 頑張ってデータ移⾏することに... CloudFormation で作成した新インスタンスにバックアップを流し込む # バックアップを取得 → redis-rdb-tools で移⾏先に Mass Insert $ aws elasticache create-snapshot $ rdb -c protocol ”xxx.rdb” | nc ”$TARGET_HOST” “$TARGET_PORT” >/dev/null Ø Aurora MySQL Reader インスタンス削除・Writer インスタンスとクラスターのエンドポイントをリネーム → 移⾏先 VPC に Aurora をクローン → Writer / Reader インスタンスを再追加 Ø MySQL リードレプリカ削除 → MultiAZ 解除 → VPC 移動 → MultiAZ 有効化 → リードレプリカ作成 

移⾏の結果 8時間に及ぶメンテナンスの末、無事に移⾏完了！ • インフラの設定変更がコード管理に (レビューができる！！) • 開発環境の新設⼿順もシンプルに • Docker 中⼼の運⽤なのでサーバーの AMI(OSイメージ) 更新も楽々 • クレデンシャル管理も SSM パラメータストアでマネージドに 従来の運⽤体制を崩すことなく技術的負債を解消 

まとめ 稼働中の AWS EC2 環境にてアーキテクチャ刷新によって技術的負債 の解消を実現した事例について紹介しました インフラ全体のコード管理とシンプルな構成管理の実現 環境間の差分をできる限りなくす 現場への負担を最⼩限に移⾏する より幸せなインフラを⽬指して今も邁進中！