この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
昨年12/18（日本時間では12/19）、AWS re:Invent 2020におけるのDr. Werner Vogels（ヴァーナー・ボーガス氏）のキーノートは皆さんご覧になられたでしょうか。
氏のキーノートセッションは毎回恒例ですが、例年だと開発環境や実行環境・AWSインフラについての話にフォーカスがあたっている印象でした。その中で「Everything fail, all the time」や「You build it, You run it」のような名言・格言が語られてきました。
ところが今回は「Developer Keynote」と銘打った上で、よりオペレーション段階の話に長く時間が割かれました。MLやインフラに特化したキーノートが別にあったことも要因のひとつでしょう。
どんなことが語られたのか？ 個人的に気になったキーワードをひろってみました。
なお記事中の訳は基本的にぼくの解釈で、確認を取ったものではないため、実際は誤読している可能性もあります。その旨ご了承のうえお読みください。
Operations are forever (1:04:48〜)
ソフトウェアが動作する時間に比べれば開発期間は短い、そしてメンテナンスが必要である
言語選択の話題から、単に開発段階だけを見るのではなく、長いスパン(long-term)で考えようというメッセージが語られました。ここから、カオスエンジニアリングはサービスの規模によらず全ての人々にとって有用であり、監視(monitoring)では死角となっている問題、つまり発生頻度は低いが致命的なイベントについて訓練を積むことが出来ると続き、AWS Fault Injection Simulator (FIS) のプレビューが発表されました。
ちなみに、今年発表したサービスの中で、氏にとって最もエキサイティングなものがこれ(AWS FIS)とのことでした。
なおこの話の中で、安全性やメンテナンス性上の観点から、AWSのサービスは様々な利点を持つRust言語を採用していることが話されました。こちらも興味深いですね！
詳細として下記のre:Inventセッションが紹介されていました。興味のある方は是非こちらもご聴講ください。
また同じ話題について、1/13のこちらのセッションでも詳細が聞けそうで今から楽しみです！
Monitoring is for operators (1:14:02〜)
モニタリングは、操作者のためのものだ
これには続きがあります。「 Monitoring means that you already know what is important. 」、つまり1990年代後半から続く、いわゆる「監視(monitoring)」というものはオペレーター（ここでは「操作だけをする者」の意）のためのものであり、「何が重要でどうなったら異常なのか、既に分かっている場合にのみ有効なものだ」としています。
この表現には実は伏線があって、同じキーノートセッションの0:50:53頃に話された「As engineers we reason our problems all the time.（我々はエンジニアとして、日々問題の解決にあたっている）」に呼応した表現かと思います。ただ操作するだけでなく、問題解決にあたるべき者にとっては、ただ単に状態をモニタリングするだけでは不十分だというメッセージとなるでしょう。
（このあたり、オペレーション/operation、オペレーター/operatorとモニタリング/monitoringという、日本語と英語のニュアンスには微妙に差があります）
このことは前述のカオスエンジニアリングからの話題を継続していますね。続けて曰く、古典的な監視(monitoring)と閾値通知(alarming)は「何が壊れたか」「その理由は？」だけを扱う、それは故障の予知をしてはくれない、それはAmazonの25年にわたる経験からきた結論であると。
そこから話は、顧客にインパクトが及ぶ前に問題を発見し解決する（ Find and resolve problems before they impact customers. ）、いちど起きた問題は二度と起きなくする、Amazonでは、大量のデータを収集し分析し、「どのようなデータやツールによってそれが可能になるのか？ 可観測性(Observability)とは？」という包括的なアプローチに着手してきたと続きます。
Log everything (1:19:30〜)
全てを記録(log)せよ
氏によれば、これは第1回目のre:Inventで語ったものとのこと。(当時としては)大胆な発言だが本気だった、とも。
実際に2012年の氏のキーノートを見直してみると、表現は違いましたが確かに話していました（1h23頃）。Data Drivenアーキテクチャのために、システムとビジネスのあらゆるレベルのメトリックを解析しようという文脈でした。
当時はデータ解析にAmazon EMRやAWS Data Pipelineを使うということで、現在のCloudWatch Logsを中心としたアーキテクチャとは少し違ってきていますが、「ログは真実の源(source of truth)」というメッセージは変わっていません。さらに、メトリクスとトレースを加えた可観測性(Observability)の3要素のなかの最初の一歩として「ログ」を据えています。
このあと話は、「ログを記録する最も簡単な方法は、標準出力(STDOUT)に出力することだ。デバッガもライブラリも必要ない」と続きます。これはAWS Lambdaやawslogsログドライバのことを指していると思われます。
Canaries should run continuously, and especially during deployments. (1:31:38〜)
カナリアは連続的に、特に開発段階から動作させておくべきである
ここでいう「カナリア(Canary)」はいわゆる早期警戒警報というか、人間が気づくよりも早く異常を検知し知らせてくれる装置の比喩としてよく使われるものですね。その「カナリア」は常に、特に開発中にこそ絶え間なく動作させておくべき、と氏はいっています。そうすることで、「たとえ顧客からのアクセスが無くても、顧客が体験する(であろう)異常を察知することができると。
Amazon CloudWatch Syntheticsはいわゆる合成(シンセティック)監視です。
シンセティック監視は通常、動作中の本番環境の正常動作・パフォーマンスを監視するという文脈で語られることが多いのですが、氏はあえてこのように言及したことで、「それだけではない」と注意を促しているのでしょう。
Be optimistic pessimists (1:34:10〜)
楽観的な悲観論者であれ
Werner氏から話を引き継いで、シニア主任エンジニアのBecky Weiss氏によるプレゼンテーションが挟まります。このなかでBecky氏は「顧客が体験するよりも早い段階で障害を検知すること（ Spotting failures before customers do ）」が勝負だと語りました。
それから、ログ収集や監視のためのシステムに対する投資に終わりが無いこと、運用の自動化は必要だがそれが全てでは無いこと、それに平行してマインドセットと経験が必要であることを説明し、彼らのチームは「楽観的な悲観論者（ optimistic pessimists ）」であろうとしていると続けます。
これは、一部推測を交えて意訳すると、ビジネスの広がり、つまり規模の将来予測については楽観的に（= 拡大するものとして）見積もり、かつ運用の健全性（operational health）については悲観的に、好奇心を持って（= 考慮漏れや改善の余地を常に探るように）あたるべきだという意味とのことと思われます。この「好奇心」の部分に該当するのが、新しい監視・観測ツールやダッシュボードということでしょう。
単に道具をそろえるだけで無く、このような考え方こそが重要だと言うことを、このあと3種類のグラフサンプルを例示しつつ解説してくれます。
ちなみに氏の締めの言葉は「Happy operating!」でしたｗ
また、Werner氏の名言をもじったような「Everything fails eventually（全てのものは結局は壊れる）」が飛び出すなど、かなり楽しいセッションですので、こちらの意味でもみなさんに是非ご覧になって欲しいです（1:33:09〜）ｗ
There is a tool that fits your needs (1:44:30〜)
あなたのニーズに合うツールがあります
正確には以下の一文です。
Now, no matter how you choose to log, monitor, trace and alert, there is a tool that fits your needs.
(意訳) いま、ログやモニタリング、トレース、アラート、そのどれについてかにかかわらず、貴方の需要に合致する道具が見つかります。
これに先だって、まず本キーノート最大のサプライズである（主観）PrometheusとGrafanaのAWSマネージドサービスが発表されました(1:40:10〜)。
また続けて、パートナー製品であるSumo Logic、Splunk、Datadog、New Relic、AppDynamicsなどにふれ、データ収集の共通化という文脈でOpenTelemetryのサポートに言及しました。
「There is a tool that fits your needs.」という言葉はこの一連の流れの最後のものなので、素直に受け取れば「AWSは多種多様な選択肢を用意していますよ」となるでしょう。けれどここは少し深読みして、CloudWatchだけに固執せず、貴方のニーズに合う監視ツールを選択してくださいというメッセージだと解釈したいと思います。
それはあながち根拠が無いことでもなくて、この一連の話の中で氏はこのようにも語っているからです。
But AWS isn’t the only company building these services.
And I’ve always said that AWS is so much more than just AWS services.
And I’d be remiss if I didn’t recognize all the tools being developed for a complete monitoring and alerting ecosystem.(意訳) しかし、AWSだけがこのような(監視・アラートのための)サービスを開発しているのではありません。
そしてAWSは、AWSサービスだけのものではありません。そう私はずっと言い続けてきました。
また当然、私は、完璧な監視とアラートに関するエコシステムのために開発されているすべてのツール群を知ろうと務めています。
AWSは常に、ユーザーの選択肢を提供すべくサービスを拡充してきた歴史がありますので、ユーザーである我々もその選択肢を享受したいところです。
みなさんも是非、みなさんなりの最高最適の選択肢を見つけてください！
まとめ
ヴァーナー・ボーガス氏のキーノートから、運用・監視に関する文言を6つピックアップしました。正直なところ目新しいメッセージといえるものはありませんが、それ故に、AWS re:Inventのキーノートという場であえて繰り返し語られたことの意味は大きいのではないでしょうか。
もちろんAWSは、AWS Well-Architectedフレームワークの柱の一つに据えるほど運用を重視しています。これまで運用が軽視されてきたわけではありません。
ただ個人的には、運用段階の話は開発段階に比べて、こういう場でフォーカスがあたることが少ない印象です。その意味でもキーノートで、ここまで長い時間が割かれたことがとても嬉しかったです。
このキーノートではこれら運用の話題の他にも、言語選択を含む開発段階の話やセキュリティ、機械学習に関するメッセージも多く語られています。2時間近くとけして短い動画ではありませんし、終始ほぼ語りだけで進んでいくのでついて行くのも大変ですが、興味が沸かれた方は是非字幕などを駆使しながら視聴してみてください！
AWS re:Invent 2020 Wave 2は '21/01/12 から開催です！
前半戦（Wave 1）のセッション・資料にもアクセスが可能です。
参加がまだの方は、この機会に是非こちらのリンクからレジストレーションして豊富なコンテンツを楽しみましょう！
7
