AWS Summit Tokyo 2019 I3-04「ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見」レポート

こんにちは、クラウドインテグレーション事業部山口です。AWS Summitも３日目となり寂しい感じですが、予定していたスピーカーセッションなども終わり、やっとセッションを聞けたのでレポートを書きます。

ロマサガ大好きで初代は３拠点制覇実績もあり、更に大好物のコンテナがテーマとなれば参加しない理由はありません、セッション会場へダッシュです。AWS Summitの事例セッションは動画公開されないことも多いので、テクニカルセッションよりも事例を優先的に聞く立ち回りも理由の１つですね。

＜注意＞このセッションは録画＆配信されるようですので、詳細はAWS公式より公開される動画を参照ください。メモの共有ということでブログにします。撮影禁止なのでテキスト中心の内容となります。

第１章ロマサガRS アーキテクチャ

Elixirをベースに開発
- 強力な並列処理が魅力
ECSベースで稼働、インフラはCloudFormationで管理
- Rubyベースのラッパーツール kumogata(kumogata/kumogata2)を使っている
- Rubyベースなので条件分岐などの記述が可能
もちろん自動化なのでオペミス０件
- 全体の99％が自動化されている
100% Dockerで構成。ポータビリティも重要だが、デプロイの安定化が魅力
- オートスケールはECSを利用(本番利用時はEKSがGAではなかった)
- デプロイ、ロールバック、オートスケール、オートヒーリング
- Fargateはスケールアウトにかかる時間(EC2のスケールアウトと同じくらい)、ロギング(CloudWatch Logsのみ)なので一部では使ったが全体的な利用はやめた。
ロギングはCloudWatch Logs、Datadog Log Management、S3などログの種類によって使い分け
- アクセスログはS3に格納しておくなど
監視はCloudWatch、Datadogを使い分けている
行動ログなどの分析は Redash を利用

感想

各ツールや技術選定の理由が明確でなるべくして出来上がったアーキテクチャと感じました。さらにKumogataなど条件分岐を記述できるとインフラに関わるコードのルール化が難しかったりするのですが、ルールの徹底、チェック機構などレビュー過程やチームとしての力が強いから事故なく管理できるのだと思います。
個人的にはCloudWatch Logsの便利なんだけどかゆいところに手がとどかない感じのもどかしさの共有を感じながら話が聞けたので記憶に残る部分が多い内容でした。

第２章負荷対策

負荷テストは、負荷テスト、改善フェーズを用意している
- テストごとの目的/ゴールも重要。明確に
- テストは1回ではなく繰り返し実行されることを前提とする
ツールはLocustを利用。シンプルなシナリオでメンテナンス性が高い
- 継続性を重視。複雑なシナリオを書ける
- Locust自体もDocker化している
- 10000req/sもさらっと出せる
単性能テスト
- アプリケーション特性をAPMで分析。
- 低負荷で改善を繰り返す。N+1クエリを検出したりする。改善後に再度試して結果を見る。
過負荷テスト
- 各コンポーネントに過負荷をかける。ボトルネック、エラー箇所、原因を特定し改善。
- EC2にだけ、RDSにだけなど負荷テストのシナリオに沿って負荷をかける。
- 一定のCPU使用率からエラーが増えるなど制約に関するシステム影響を見つけることができる。
高負荷テスト
- スケールアウト/インの確認
- シナリオごとの負荷特性を確認(リセマラ、イベントなど特定の更新APIを大量に引くなど)
- システムサイジングも目的
障害テスト
- 一部のコンポーネントにわざと障害を起こしてサービスの継続を確認する。
- 負荷テスト中にAmazon Auroraを停止させる(エンドポイントの解決による名前解決キャッシュが影響してないか、などの問題を確認する)
長時間テスト
- 一晩負荷をかけてメモリリークやファイルディスクリプタの枯渇などを確認する
- CloudWatch Logsなど料金の目安にもできる
PDCAを高速化する。
- 素早くスケールするツールを使う
- デバッグAPIを使うなどテスト準備にかかる時間を短縮される工夫をする
  - 例えばプレイヤー資産を付与するデータを用意する必要がない(プレイヤー資産がないとN+1も検知しずらい)
- 何度でも壊して作れるインフラ(CloudFormationで)
- メトリクス監視のダッシュボードを用意しておく

感想

テストを実施するときは、テストをすることがテストの目的にならないことが大原則であること、テスト(テスト資産)は繰り返し使われることを前提とすることなど、注意しなければならないことが当たり前のように考えられえていて、お手本のようで非常に参考になる内容でした。
また、Amazon Auroraはクラスタエンドポイント、リーダーエンドポイント、インスタンスエンドポイント、カスタムエンドポイントがあり、特にフェイルオーバー発生時にリーダーが昇格してマスターになった際、接続先はクラスタエンドポイントの名前解決で切り替えが行われます。このフェイルオーバー試験をしっかり実施しておかないと名前解決のキャッシュで切り替え前のマスターに接続してしまい結果アプリケーションエラーが発生するケースなどありますので、その点を障害テストで実施することも非常に重要です。

第３章サーバレス運用

ECSスケーリングの工夫
- ECSスケールの課題、スケールアウトとイン時の停止するECSとEC2の整合性がとれない
- CloudWatch AlarmでEC2をスケールアウトさせるが、その際にLambdaをキックしDesired capacityを一致させる
- スケールインはライフサイクルフックを使ってオートスケールグループ内のインスタンスステータスを変えて停止処理をペンディングさせる。その後 LambdaにてEC2インスタンスIdからコンテナをDrainingさせて停止したいEC2を停止する
デリバリーパイプラインは、JenkinsとCodeBuildを組み合わせて使っている
サーバレスバッチとして、Docker imageをCodeBuildからビルドしたあと、再度CodeBuildからdocker runさせることでバッチシステムとして利用している
- ビルド済みのアプリケーションを再利用できることがメリット。コストも下げることができる
- 実際にはアイテムドロップシミュレータ、DBマイグレーションテストに使っている
自動復旧は、DatdogのアラートからSNSを通してlambdaをキックしECSを特定し、コンテナをDrainingして復旧処理前後でslackに通知もすることで対応
- Aurora障害もfailoverイベントをトリガーとしてローリングアップデートをECSに指示してリカバリしている