早朝の5K Raceに参加し、その後、マラソンの会場でもあったマンダレイベイでセッションを受けてきました。 5K Raceと今日参加したモニタリングのベストプラクティスセッションについてご紹介します。
参加したセッションはCOP320 | Best practices for end-to-end digital experience monitoringです。 Breakout sessionのため講義型のセッションです。
5K Race
5K Raceとは
re:Inventでは恒例となっている早朝のフランク・シナトラ通りを往復約5kmを走るというイベントです。
※セッションの説明より
トレーニングウェアを持参し、楽しいレースに参加する準備をしよう。毎年開催されるre:Invent 5Kレースのゴールを目指して、参加者と共にチャレンジしよう。参加費は無料。コースはマンダレイ・ベイのミケロブULTRAアリーナを発着点とし、フランク・シナトラ・ドライブに沿って進む。ベネチアン・サンズのホワイエにあるコミュニティ・イベント・デスクで登録し、ゼッケンとパケットを受け取ってください。
Bring your workout gear and get ready to join the fun. Embrace the challenge alongside fellow attendees to cross the finish line of the annual re:Invent 5K race. Participants of all skill levels are welcome and there is no fee to participate. The course begins and ends at the Michelob ULTRA Arena at Mandalay Bay and follows Frank Sinatra Drive. Visit the Community Events desk in the Venetian Sands Foyer to register and pick up your bib and packet.
まず参加するにはゼッケンを受け取る必要があります。 ベネチアンホテルのレジストレーション近くに5Kマラソンの受付がありますが、今年は基調講演のあった2日目になくなったと聞いています。
レース当日は朝5:15にベネチアンホテルからシャトルバスが出ており、私もこの便でマンダレイベイへ向かいました。 手荷物を預かってもらえるので、Badgeとランニングウェア、ゼッケンを忘れないよう持参します。レース開始まで肌寒いので上着は持って行っていくと良いです。
その後、案内に従って5Kマラソンの待機列に並び、スタート地点のMichelob ULTRA Arenaから出走です。 アリーナにはバナナやスムージー等の軽食や飲料が置いてありました。 手荷物もここで預けられました。
出走順
- Rabbit（速い）
- Tiger（なだらかなペース/ジョギング向け）
- Unicorn（歩く方向け）
任意ですが、上記の順番で出走出来ます。 Rabbitは3'00台のランナーが走っているようです。
私も完走し、22分程掛かりました。 ゴール後、たまたまチェキを撮ってもらえてラッキーでした。 5Kマラソン後、一旦宿泊先モデルに戻って汗を流し、セッションに参加するため再びマンダレイベイへ向かいます。
エンド・ツー・エンド・デジタル・エクスペリエンス・モニタリングのベストプラクティスセッション
システム全体の監視についてどう要件をまとめて設計すべきかを検討するため、このセッションに参加しました。
エンドツー・エンド・デジタル・エクスペリエンス・モニタリングとは？
デジタル・サービスやアプリケーションのエンドユーザー体験を追跡し、最適化するための包括的なアプローチです。 End-to-end degital experience monitoring is a comprehensive approach to tracking, and optimizing the end user experince with degital services and applications.
例えば、ユーザがショッピングサイトで買い物をしていて、その挙動を監視する場合、どこでボトルネックや障害が起こっているかを知るためのモニタリング（監視）といったことです。2つ以上の指標を合わせた合成メトリクス、バックエンドインフラストラクチャのメトリクス、APIやネットワークの状態を監視します。 いわゆるオブザバビリティの側面もあります。
監視を行う前に決めること
SLA(Service Level Agreement)を定めて、SLAを達成するための具体的な目標として(Service Level Objective)を策定し、SLI (Service Level Indicator)でSLOの達成状況を評価します。
例えば、SLAを「月間サービスの稼働率は99.5%以上」とします。 次にSLOの1つとしてAPIの応答時間を「95%のリクエストで200ms以内」とします。 最後にSLIで稼働率 = (正常に稼働した時間) ÷ (合計時間) × 100として、月間正常稼働時間が700時間だった場合、 700 / 720 * 100 = 97.2%となり、SLAを達成出来ていないことになります。
SLAを満たせるようどこに問題があるかを突き止める点でもこういった監視要件は重要となります。
監視対象のシグナルを特定し追跡するためのベストプラクティス
これらのサイクルを図にするとのこのようになります。
まずSLAを満たすためにSLIでの評価結果によってはSLOを見直し、これらのサイクルを繰り返し反復することでシステム全体の監視を改善していくアプローチがベストプラクティスとして提唱されていました。
システムの状況は常に同じではありませんので、SLAを基準に既存の監視を見直すのは現環境に合った適切な改善であると認識出来ました。
付録
一例となりますが特定のサービスを監視する際に利用出来るAWSの仕組を記載します。
データベースの監視
クエリパフォーマンス、ユーザやクエリの衝突、キャパシティ制限（CPUやストレージ等のリソース）、データベース設定の問題、アプリケーションとデータベースの問題を関連付ける。アプリケーションのシグナル
アプリケーションの状態やパフォーマンス、エラー情報等が考えられます。
最後に
このセッションは予約していなかったのですが、意外と席が空いており、当日参加でも問題なく参加出来ました。 エンド・ツー・エンドの監視要件として、SLAを達成するためにSLOを定めることで、システム全体の正常性を保ち、また改善を続けるための手法としてのベストプラクティスを知ることが出来たため、今後の監視手法に取り入れてみようと考えています。
