AWS GameDay で実践トレーニング　- Design for Failure -｜atlax/アトラックス

AWS GameDay で実践トレーニング
- Design for Failure -

- 2020/11/25

AWS GameDay とは

毎年、re:Invent で開催されている、世界中から多くのエンジニアが参加するコンテスト要素も含んだイベントです。

Unicorn Rental という架空の会社の新⼊社員として、すでに退職してしまった前任者が構築した AWS 環境を引き継ぎ、その上で発生するさまざまなトラブルをチームで解決することでスコアを獲得しいく、実践型トレーニングとなっています。2017年に開催された AWS GameDay における Unicorn Rental 社の CEO の挨拶動画が公開されていますので、ご紹介しておきます。

・AWS re:Invent 2017 - AWS GameDay - YouTube（1分09秒 / 英語）　※外部サイトへ

本イベントは、re:Invent 現地だけでなく、AWS Loft Tokyo など日本でも開催されることがあります。今回、APN パートナー向けにオンラインで開催されることになり、AWS 技術の力試しをしようと参加してきました。今回は、24社・30チーム（120名）が参加しました。

あっと言う間の 4時間半・・・

イベントが次々と仕掛けられてくるため、昼ごはんを食べるのも忘れて、チームで奮闘すること 4時間半、時間はあっと言う間に過ぎていきました。

我々のチームは途中、トップ3 にランクインするまで健闘しましたが、終了時間近くの激動のバトルに勝ち残れず、惜しくも結果発表に掲載してもらうことはできませんでした。しかしながら、弊社から参加したチームはトップ10 以内に 2チームがランクインするという結果を残すことができました。

（公式の結果発表は、AWS GameDay Online APN Cup.vol1 結果発表！を参照ください）

GameDay スコアボード

振り返ってみると、全てのサービスで成功率100％をいち早く達成するなど、日頃の業務で身につけた AWS の知識や、安定稼働へのこだわりが成果に現れていました。また、コンテナが得意な人、インフラが得意な人など、得意な領域が異なるメンバー同士が、しかもオンラインで、うまく分担・連携できるかというチーミングの要素も大きかったと感じます。

一方で、さらに改善する余地があった点は「障害が起きたときに、いかに迅速に復旧させるか」でした。ゲーム性に起因するところもありますが、今動いているサービスが安定稼働していることだけに満足せず、パフォーマンスの改善や予期せぬサービス停止への対策をしておくことができれば、さらに高い成績を達成できたのではないかと思います。

迅速に障害から復旧させる　- Design for Failure -

予期せぬサービスの停止に備える考え方として「Design for Failure」という原則があります。あらゆるものは壊れる宿命にあることを前提に、サーバが壊れること（さらにいうと災害によりデータセンターが停止すること）を想定した設計をすることが基本的な考え方です。

Werner Vogels も、re:Invent のキーノートを始め、さまざまな場所で以下のように述べています。

"Everything fails, all the time" - Werner Vogels (CTO, Amazon.com)

障害が起きることは避けられませんが、クラウド上には豊富なリソースや障害に備えるためのサービスが提供されていますので、それらを活用することで可用性を高めることが可能です。

モニタリングにより素早く稼働状況を把握する

AWS はモニタリングのためのサービスも充実しています。それぞれの用途に合わせて、組み合わせて活用していきましょう。

- Alarm … CPU 使用率などのメトリクスを収集するサービスです。
- Event … AWS リソースの変更イベントを他のサービスに連携します。
- Logs … ログファイルの監視、保存、検索の一元管理ができます。
アプリケーションが処理するリクエストに関するデータを収集するサービスです。アプリケーションやその基盤となるサービスの構成を可視化し、パフォーマンスの問題やエラーの根本原因を特定するのに役立ちます。
AWS サービスそのものの稼働状況を収集・可視化するサービスです。自分が利用しているAWS アカウントに影響する可能性がある問題が表示されますので、AWS で稼働しているシステムで何かしらの障害があった場合には確認すると良いでしょう。

迅速に復旧するための仕組みをつくる

サービスの停止時間をできるだけ短くするためには、複数のアベイラビリティゾーンでシステムを構成すること（マルチ AZ 構成）を検討します。このとき、Elastic Load Balancer（ELB）を活用すれば自動で正常なターゲットにのみリクエストが振り分けられるので、サーバー 1台が障害で停止してしまってもリクエストを正常に処理し続けることができます。

ビジネスニーズと高可用性実現コストのトレードオフを考える

とはいえ、高可用性を実現するためにはコストも発生するのが現実です。そのため、障害発生時のビジネスインパクトとコストのトレードオフを考え、例えば「リージョン障害にも備える必要があるか？」といったことを決めていきましょう。

AWS GameDay は、このようなクラウドのベストプラクティスが実装できるかを試す、という意味でも実践的なトレーニングになっていました。また機会があればリベンジしたいと思います！

最後に・・・

最後に、クラウドを活用する際には今回取り上げた可用性のみではなく、「運用」「セキュリティ」「パフォーマンス」「コスト」などビジネスに照らして多面的に評価し、設計していくことが求められます。クラウド上でワークロードを設計および実⾏するための考え⽅・設計原則・ベストプラクティスについては、AWS Well-Architected Framework として公開されていますで、別の機会にご紹介したいと思います。

AWS GameDay で実践トレーニング - Design for Failure -