echo("備忘録");

IT技術やプログラミング関連など、技術系の事を備忘録的にまとめています。

【AWS】ソリューションアーキテクトアソシエイト試験に合格しました

AWS SAA-C03 ソリューションアーキテクトアソシエイト試験

はじめに

お久しぶりです。

前々回のAWS Summit 2023のブログでも少し触れたかもしれませんが、AWSソリューションアーキテクトアソシエイト試験(SAA-C03、以下「SAA」と表記)を受験し、無事合格しましたので、その体験記＆情報などをブログに残そうと思います。

なおAWS認定試験の規約上、具体的な試験内容(どんな問題が出た、など)は記載できませんので、ご了承ください。

そもそも、受験の動機は？

  • 会社での2022年度の下期目標として「AWS SAA試験合格」を掲げていたが、業務がめちゃくちゃ忙しい＆YAPC::Kyoto 2023などの準備もあり、全然時間が取れなかった
  • AWS Summit会場には「認定者専用ブース」という、何かしらのAWS認定資格を持っている人しか入れないブースがあり、今年こそはそこに入りたい！と思ったため。
    • なお結論から言うと、めっちゃ人が多くてほとんど入れませんでした...
    • ちなみにこのブースには、机＆椅子（充電用コンセント込み）や、ちょっとしたお菓子なんかが置いてあります
  • 上記の理由＆「1か月で取得」みたいなブログ＆動画もあり、「いっちょ自分もやってみるか」と思ったので

勉強期間は？

21日（3/24申し込み、3/25～4/16勉強期間、4/17試験）

勉強時間は？

一日平均3～4時間くらい（休日はさらに+1～2時間くらいしたかも）

勉強教材は？

ちなみに動画・ブログなどを参照する場合、必ず「SAA-C03版対応かどうか」をチェックしてください。
旧版であるSAA-C02版と比べ、SAA-C03版は試験範囲＆試験の難易度が大きく変わり難しくなっているため、要注意です。(SAA-C02の内容が全く役に立たない訳ではないです)

勉強方法は？

自分は期間が短かったのもあり、模擬試験ベースで下記の勉強方法でした。

  • 公式やUdemyの模擬試験を解く
  • 解説を読む＆わからない言葉を調べる
    • 1回目は解説を読んだ上で、正解・不正解に関わらず、分からないことはネットで調べました。
    • 2回目は時間もなかったので、不正解だった問題のみ、分からないことをネットで調べました。

なお最終的にAWS公式やUdemyの模擬試験を2周しましたが、もっと時間をかけるべきだったと思います。

また、最終的に上記模擬試験で75%～80%（できればそれ以上）が取れるくらいが目安ではないかなと思います。(もちろん、あくまで目安です。模擬試験で50%前後の合格率しかなかったけど、本試験は合格だったという人もいるので、あきらめないことが肝心です)

試験結果は？

試験結果ですが、下記の通りです。(タイトルで合格したというのはネタバレ済みだと思うので。なお720点以上で合格です。(※1))

試験自体は「多分ギリギリ合格か、ギリギリ不合格かのどっちかだろうなあ」という感想でしたが、まさかここまでギリギリとは思いませんでした。

ちなみに周りからは「最も効率がいい勉強をしたんだね（笑）」とさんざん言われました。

受けてみた感想＆アドバイス

  • 今回は21日という短期間で運良く合格しましたが、やはりもう少し長い期間を勉強に充てるべきだと思いました。(だいたい2～3か月)
    • 今回は動画やドキュメント参照で終わってしまいましたが、可能であればAWSを実際に触ると、より理解が深まります。
    • あと模擬試験は3周くらいできると、より理解が深まるかなと思いました
  • 模擬試験をそれなりにやれば、試験時間は良い感じ(短過ぎず長すぎず)だと感じました。
    • とにかく分からない問題でハマらず、分かる問題から確実に解いていくことが大事
    • 分からない問題が多少あっても「どうせ15問は採点対象外なんだから」と割り切る(※2)
  • 今まで知らなかったサービス・機能・仕様を試験勉強を通して学ぶことができ、それが非常に大きかったです
    • 実際、業務やコミュニティなどの活動にも生かされています
  • 実務でAWSを触っている人でも、落ちる可能性は十分にある内容です。
    • 業務で触っているからと言って、タカをくくらない方がいいです。

まとめ

これから受験する皆さんも、ぜひ頑張ってください。

それでは、今回はこの辺で。

補足

※1：最低100点～最高1000点。なお72%以上というのが合格の目安ですが、配点が固定というわけではないらしいので、一概に72%正解したから合格...という訳ではないみたいです。(基本情報技術者の午前試験ような感じなのかも)

※2：問題自体は65問だが、採点対象になるのは50問で、残り15問はAWS側が今後の試験の改善・調査などのために設定している問題です。(ただし、どの問題が採点対象か否かというのは分かりません)

【Perl】YAPC::Kyoto 2023で登壇しました

YAPC YAPC::Kyoto yapcjapan

はじめに

2023/3/19(日)に、YAPC::Kyoto 2023というJPA(Japan Perl Association)主催の一大イベントが京都リサーチパークで開催されました。

yapcjapan.org

そしてこのイベントで「CloudWatchエージェントとCloudWatchで行うアプリケーション監視」という内容で登壇させて頂きました。

今回は（今更ながら）YAPC::Kyoto 2023の感想をブログで書こうと思います。

ちなみに発表資料は下記となります。(なおデザインから分かる通り、今回は会社の業務として参加しています)

speakerdeck.com

発表資料の訂正

25ページ目に「CloudWatchエージェント独自のメトリクス」として「CPU使用率」という記載がありますが、これは誤りです。失礼しました。

CPU使用率はCloudWatchエージェントを使用しなくても、CloudWatch上でメトリクス「CPUUtilization」の値で確認できます。

雰囲気とか

今回は3年ぶりのオフライン開催(正確にはハイブリッド開催)ということもあり、かなり盛り上がってた感じです。

また（弊社もそうですが）さくらインターネットさん、はてなさん、マネーフォーワードさんなど、有名どころの会社さんもいろいろブースを出展しており、「各社Perlにも結構力を入れているんだなあ」と改めて感じました。

個人的には弊社に入るまでPerlを全く書いたことがなかったり、昨今のPerlの評判もあり正直半信半疑な感もありましたが、今回YAPC::Kyoto 2023に参加して改めて「Perlもまだまだ熱いなあ」と強く感じました。

まあ、登壇内容はPerlに1ミリもかすってないわけですが...

登壇してみて

正直どれだけの方が聴きに来てくれるかが不安でしたが、結構の方が聞きに来てくれて、とてもうれしかったです。(小並感)

というか、リアル登壇ってめちゃくちゃ久しぶりな感じだったので、やっぱりオフラインっていいなあと思いました。(AWS Summitでも感じたことですが)

今後も機会があれば、こういうオフラインでの登壇・発表機会を増やしていきたいし、そのためのネタ(=スキル)も増やしていきたいなと思いました。

そのほか少しの間、弊社企業ブースにいましたが、グッズの評判も結構よかった＆自分の発表に対して質問をしてくれる方もいたりして、なかなか充実した時間を過ごせました。

印象に残ったセッション（といっても、あまり聴く時間が取れなかったですが...）

※「my new error...」（井手優太 様）

  • エラーハンドリングに関する話(=try/catchなど)
    • まさに今回のテーマにぴったり
  • 今回数少ない、TypeScript/JavaScriptに関する話
    • 他の言語でも応用できる内容です
  • いわゆる「Result型」を使おう！という内容
  • その他、監視体制に関する話など
  • めちゃくちゃ有用な内容で、とても役に立った。(特にResult型)
    • Result型については、また後日書きたいなと思っています。

なお詳細は、井手様の下記ブログに記載がありますので、ぜひご参照ください。

blog.ojisan.io

全体的な感想

  • やっぱりリアル会場開催っていいなあ
  • 自分の中で、Perlに対する認識が結構変わった。
    • しかしやっぱり自分はTypeScript/JavaScriptファーストかな...
  • 強いて言うなら、同じ題材(AWSとか)を同じ時間にかぶせるのは避けてほしかった
    • 「qron: Cloud Native Cron Alternativeの今」を聴きたかった...

ギャラリー

それでは、今回はこの辺で。

【AWS】AWS Summit 2023に参加しました

AWS AWS Summit 2023

はじめに

お久しぶりです。

YAPC::Kyoto 2023が終わってから、業務がめちゃくちゃ忙しかったり、AWSソリューションアーキテクト試験を受験してたりで、全然ブログを書く時間がありませんでした。

で、久しぶりの記事ですが、4/20(木)～4/21(金)に幕張メッセで開催された、AWS Summit 2023の参加感想になります。(今年は4年ぶりにオフラインのみでの開催でした)

公式サイト：https://aws.amazon.com/jp/summits/tokyo/

今年の話題

今回のAWS Summit 2023最大の話題といえば、4年前のAWS Summit2019年において、

などなど、さんざんパイプ椅子でお尻がやられる報告を受けてか、なんと公式からクッションの配布がありました。(各日先着2,800名)
ちゃんとフィードバックが反映されてましたね

これで今年はお尻は大丈夫だぜ！

....とは残念ながらならなかったですが(やっぱりお尻は痛かった)、ちゃんと参加者の意見を活かしてくれているのは素晴らしいと思いました

セッションの全体的な感想

さすがに一個一個セッションの感想を挙げてるとキリがないので、概要のみ

サーバーレス化がより浸透

  • 自治体システムのサーバーレス化(神戸市＆浜松市)
  • メールサーバーをEC2ホスティングからSESに(ニンテンドーシステムズ株式会社)
  • 「まずサーバーレスから考える」
  • サーバーレスがイケてる...よりは、むしろそれだけ運用管理工数が馬鹿にならない・問題の重要度が高いとされてるという実感

機械学習・AI・データレイク・ビックデータ解析の進化

  • 上記の機能がより進化
  • 大量データを扱えるリソースの進化(EMR, RedShift, S3 Graviton)
  • AWS Bedrock, AWS CodeWhisper
  • 「データは直感に勝る」

「Developer Lounge ミニセッション」がかなり熱かった

  • AWS Lambda PowerToolsを使いこなそう(AWS 福井様)
    • AWS PowerToolsを用いて、Lambdaの様々な状態(コールドスタート、関数単位での実行時間など)をCloudWatchで可視化できる
    • AWS PowerToolsは、Lambda LayerでURL指定するだけで使用可能。(pip installやnpm installなどでもOK)
    • これを使えば、ボトルネックの発見＆改善に役立てたり、運用監視にめちゃくちゃ役立つ
    • 個人的にマジで神ツールだと思った
  • 10分で役立つ！SQS + Lambdaという非同期処理黄金パターン(AWS 白石様)
    • マイクロサービスなどで必須の非同期処理について、SQSを使用した実装方法を説明
    • ただSQSを使うだけでなく、トリガでLambdaを起動するとキューの各種処理を自動でやってくれて、非常に相性がいい
    • 分散処理に対応しているのもおススメ
    • (自分補足)「データを欠落することなく、どこかで確実に処理を行わせる」ということを行う際にも、SQSはおススメ

その他

  • 全般的に運用監視、オブザーバビリティのセッションが多く、「サーバーレス化がより浸透」でも記載した通り「運用管理工数の問題の重要度が上がっている」印象を受けた
  • 「PayPayにおけるマルチリージョン環境への取り組み(株式会社PayPay)」で紹介されていた「レイテンシーの確保のため、あえてマルチAZにしない」構成は衝撃的だった(決済って、めちゃくちゃミッションクリティカルな分野なのに)

参加してみて

やっぱりオフラインっていいですね。
ちゃんと現場の独特の雰囲気を味わえるし、カメラ越しではなく、リアルで人と触れ合えるというのはやっぱり素晴らしいです。

そしてなにより、今までカメラ越しやSNSでしかやり取りしてなかった人とリアルに挨拶したりお話しすることもできましたし、私のことを知ってくれていることもいて、非常に嬉しかったです。
また、そういうのがとても大きなモチベーションにつながります。

なんていうか、本当に素晴らしいなあ、と思いました。

それでは皆さん、次はAWS Dev Day 2023でお会いしましょう！

【VS Code】Remote SSHをWindows+WSL2で動かしてて困ったこと

vscodejp Visual Studio Code Remote SSH WSL2

はじめに

前回の記事でも書きましたが、先日、VS Code Conference 2022-2023で登壇しました。
運営の皆さん＆聞いてくださった皆さん、ありがとうございました。

その時のスライドが以下なのですが、このスライドの17枚目で「Windows+WSL環境でRemote SSHを動かす場合、少しやっかいな部分がある」と記載しています。(17枚目に直リンできない...)

speakerdeck.com

今回は、その「やっかいな部分」について記載します。

WSLでも、Windowsフォルダを参照する

VS CodeでWSLに接続していても、Remote SSHで鍵認証で接続する際、鍵ファイルはWindowsのフォルダを参照します。

例えば鍵ファイルのパスを ~/.ssh.id_rsa のように指定すると、接続する際にはC:\Users\(ユーザー名)\.ssh\id.rsaと、Windowsのホームフォルダを参照します。

また/home/(ユーザー名)/.ssh.id_rsa のように絶対パスで指定すると、接続時に「そんなファイ存在しない」とエラーになってしまいます。(Windowsで/home/(ユーザー名)/.ssh.id_rsaみたいなパス指定は無効から)

なので、Windows+WSLの場合、例えWSLに接続していても秘密鍵はWindows側フォルダに置き、Windows形式のパス指定する必要があります。

※私がやり方を知らないだけ？てか、私が変にこだわっていただけで、そもそもそういうものなのかも...

WSLでも、ssh接続にコマンドプロンプトを使用する

もう一つ厄介だなあと思った部分がこれで、Windows+WSLの場合でも、Remote SSHはssh接続時にコマンドプロンプト(cmd.exe)を使用して接続します。(wslでもbashでもない)

これの何が厄介かというと、コマンドプロンプトはWindowsからWSLフォルダを参照する際の \\wsl$\(ディストリビューション名)\home\(ユーザー名) という形式でのパスが使用できないんです。(「CMD では UNC パスは現在のディレクトリとしてサポートされません。」とエラーになる。なおPowerShellは使用可能)

なので、WSL側のフォルダを参照することが、どうしてもできなかったです。

ちなみにこれ、Windowsのデフォルトシェルを変えたら、ちゃんと変わるんですかね？
試せてない(やり方を知らない)ので、ちょっと不明です。

なお、以下の方法では使用するターミナルを変更できませんでした。

Remote SSHにも、それっぽい設定はあるけども

実はRemote SSHにも「Remote SSH:Path」という「SSH実行可能ファイルへの絶対パス」を指定する設定があり、ここにターミナルの実行ファイル(*.exe)のパスを記載すればいけるのでは？と思っていたんですが...

実際には、これはsshコマンドを行うための実行ファイルの設定でした。( ssh -V の「ssh」の代わりのコマンド。もちろんデフォルトはssh)
そりゃあ、PowerShellなりwslなりを指定してもダメですよね。(※1, ※2)

ただ、やはり「WSLなのにwsl.exeで動かない」というのはみんな使いにくいようで、実際その旨のissueも上がっています。

Remote-SSH: Fails to discover WSL SSH · Issue #937 · microsoft/vscode-remote-release · GitHub

またこのissue内で「*.batファイルでうまいこと書けばチェック通るよ」というコメントを残している人もいて「頭のいい人はいるんだなあ」と改めて実感しました。(結果的には、この方法だと最後の実際にssh接続するところでエラーになって、接続出来ないのですが...)

https://github.com/microsoft/vscode-remote-release/issues/937#issuecomment-514714615

※1）
Remote SSHでは、ssh接続前に「Remote SSH:Pathの実行ファイルを使用して実行ファイル -Vというコマンドを実行し、その実行結果に「OpenSSH」という文字が含まれているか」というチェックを実施しています。
なのでRemote SSH:Pathにsshに対応していない実行ファイルを指定すると、このチェックでエラーになります。

※2）
ssh -Vコマンドを実行した場合、例えば以下のような文字列が表示されますので、この文字列の「OpenSSH」の存在をチェックしています。

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

まとめ

以上、Remote SSHをWindows+WSL2で動かしてて困ったことについて書きました。

が、結論から言うと「Windows+WSL環境でも、秘密鍵はWindows側のフォルダを参照する」ということさえ割り切ってしまえば、全く支障はないと思います。

なお「WSLで作成した秘密鍵をWindows側にコピーしたら、パーミッションが緩くなってAccess Denied(public key)になる＆chmodでもパーミッションが変えられない！」という場合は、私が前々回に書いた 【WSL2】Windowsのファイル・フォルダをchmodする

それでは、今回はこの辺で。

【vscode】VS Code Conference 2022-2023登壇後記

vscodejp Visual Studio Code

はじめに

2023/01/21(土)に、VS Code Conference 2022-2023という、VS Code Meetup主催のVS Codeの一大イベントが開催されました。(オンライン＆オフラインのハイブリッド方式)

vscode.connpass.com

このイベントで「Remote SSHで行うVS Codeリモートホスト開発とトラブルシューティング」という内容で登壇を行いました。(途中、少しグダったところがあってすいません)

今回は、その登壇後記＆感想についてです。

なお発表資料は、SpeakerDeckで公開しています。

speakerdeck.com

感想：現地行きたかったよう...

今回、私は諸事情によりオンライン参加でした。

が、配信で見てて思ったのは、やはり「オフライン参加したかったな」ということでした。

まずオフラインの独特の感じが良かった＆あの雰囲気の中で登壇したかったですし、何より懇親会などを通じて、参加した方々との交流・(技術者同士の)つながりは、何物にも代えられないよな、と改めて実感しました。(ちなみにそれを後になって後悔＆引きずってしまって、ちょっと落ち込んでしまっていました)

以前にオンライン登壇後の懇親会で「つながりなどはオフラインじゃないとなかなかできない」という話をしたことがあるんですが、本当にその通りだなと思いました。

なので(VS Code Conferenceに限らず)次に大きなイベントで機会がある際は、ぜひ現地に行って登壇したいな、と強く感じました。

...ただ、そうなると地方在住者は「お金の問題(交通費・宿泊費など)」が出てくるんですけどね。

しかし、やはり参加した方々との交流・(技術者同士の)つながりはこういうイベントでないとなかなか体験できないので、極力そういうことは気にせずオフライン参加するべきだと強く感じました。

頂いた質問への回答

なお、登壇後に質問を頂いたんですが、その回答時に若干変な空気になってしまった感も否めないので、ここで改めて回答させて頂きます。

Q：リモートホストがインターネットに接続できない場合でも接続可能ですか？(以前はリモートホストがインターネットに接続できないとダメだったような...)

これは「接続可能」です。

実際、デモで使ったEC2のアウトバウンドを全てNG(=インターネット接続不可)にしても、接続できました。

これはおそらくRemote SSHの挙動が

  1. はじめにVS Code Serverをリモートホストにダウンロードする
  2. 1がNGの場合、ローカルにダウンロードする

という挙動を行うからではないか？と思っています。(設定項目「Local Server Download」で変更可能)

なので、諸々の理由で一切インターネットに接続出来ないホストでも、Remote SSHから接続可能です。(もちろんリモートホストのインバウンド設定で「SSH接続を許可」は必要です)

Q：configファイルにhostsなどOSの接続設定ファイルを使用する場合、その編集はどのように行うのでしょうか？

これは、OSのhostsファイルは管理者権限でないと開けないが、それを編集するにはどうすれば？という質問になります。

これですが、どのOSのhostsファイルを使っているかによって異なります。

  • Windows：VS Codeを「管理者として実行」メニューで起動すれば、普通に編集可能です。
  • Mac/Linux(WSL含む)：sudo vim /etc/hosts など、管理者権限でhostsファイルを開いて編集する形になります。
    • Macなら、root権限でログインすれば出来る？(未確認)

まとめ

何だかんだで、非常にいい経験になりましたし、モチベーションアップにもなりました。

このような機会を下さった運営の皆さん、聞いてくださった皆さん、ありがとうございました。

また機会があれば、ぜひ来年も登壇したいと思っています。(可能であればオフラインで)

告知

明後日の2/1(水) に「TechFeed Experts Night #12 VS Codeに負けるな！エディタ戦争最前線」というイベントで、「サーバーレスWebアプリケーション開発・運用で役立ったVS Code拡張機能」というテーマで10分弱ほど発表をさせて頂くことになりましたので、よろしければご視聴ください。

techfeed.io

また少し先になりますが、3/19(日)に京都リサーチパークで行われるJPA(Japan Perl Association)主催の「YAPC::Kyoto 2023」にて「CloudWatchエージェントとCloudWatchで行うアプリケーション監視」という内容で発表を行うことになりましたので、こちらもよろしければお願いします。

yapcjapan.org

それでは、今回はこの辺で。

【WSL2】Windowsのファイル・フォルダをchmodする

WSL2 Windows

今回の内容

WSL2(Windows Sussystem for Linux 2)にて、(Linux側ではなく)Windows側のファイル・フォルダをchmodで権限を変える方法についてです。

詳細について

WSL2は、WindowsでLinuxを扱えるということで、(昨今は稼働サーバーがLinuxということが多いのもあって)開発環境として利用したり、Windowsのファイル・フォルダなどをLinuxベースで扱えたりと、大変便利です。

しかし、実は「(WSLではなく)Windowsのファイル・フォルダは、chmodで権限を変えられない」という制約があり、これが結構不便だったりします。

特に、リモート接続時などに使用する秘密鍵ファイルは、変に公開範囲が広いと接続時にエラーになるので(public key)、権限を変更したいのですが、

  • Windowsのファイル・フォルダは、chmodで権限を変えられない
  • WSL側で権限変更してからWindows側にコピーしても、なぜかWindows側で権限が変わってる(=公開範囲が広くなってる)

ということがあるので、Windowsのファイル・フォルダも、chmodで権限を変えたい、というケースがあります。

やり方

で、いきなり結論ですが、下記の手順を踏むことで、Windowsのファイル・フォルダも、chmodで権限を実行できるようになります。(全てWSL2側での作業です)
参考： https://www.fixes.pub/program/695629.html

  1. /etc/wsl.conf ファイルを開く。(なければ作成する)
  2. /etc/wsl.confに下記の内容を記載し、保存する
  3. PCを再起動する。(これは無くてもできるかも...ただ再起動すれば確実)
# Enable extra metadata options by default
[automount]
enabled= true
root= /mnt/
options= "metadata,umask=22,fmask=11"
mountFsTab= false
# Enable DNS – even though these are turned on by default, we'll specify here just to be explicit.
[network]
generateHosts= true
generateResolvConf= true

上記手順を踏んだ後、WSL側でWindows側のファイル・フォルダをchmodしてみると、ちゃんと権限が変えられると思います。

wsl.confと.wslconfigの違いについて

とりあえず問題は解決しましたが、今回設定を記載したetc/wsl.confファイルについて、

Windowsのユーザーフォルダ(デフォルトではC:\Users\<ユーザー名>)に.wslconfigってあったよな。あれとの違いは何だ？

と思ったので、調べてみました。

といっても、これはマイクロソフト公式サイトで、これ以上ないほど分かりやすい説明がありました。
WSL での詳細設定の構成 | Microsoft Learn

簡単に言えば

ということみたいです。(ちなみに、先述の設定を.wslconfigに書いても、chmodで権限変更はできませんでした)

告知

今週の土曜日(2023/1/21)に「VS Code Conference Japan 2022 - 2023」という、VS Code Meetup主催のVS Codeの一大イベントが開催されます。

このイベントで「Remote SSHで行うVS Codeリモートホスト開発とトラブルシューティング」という内容で登壇させて頂くことになりましたので、よろしければぜひご参加ください。

ちなみに内容は、以前投稿した下記記事をベースに、デモや発生頻度が高い「接続できない」事例も含めて紹介する予定です。
【VS Code】Remote SSHでSSH接続する - echo("備忘録");

vscode.connpass.com

それでは、今回はこの辺で。

【AWS】CloudWatchアラームの「欠落データの処理」について理解する

AWS CloudWatch

はじめに

前回、AWS Advent Calendar 2022の関連記事として、CloudWatchのメトリクスに関する記事を書きました。

今回はその続き？ということで、CloudWatchアラームにある「欠落データの処理」についてです。

ちなみに、「欠落データの処理」はCloudWatchアラームの「条件」内にあります。(デフォルトでは表示されていませんが「▼その他の設定」をクリックすると出てきます)

参考資料

前提：「アラームを実行するデータポイント」について

「欠落データの処理」の前提として「アラームを実行するデータポイント」を先に説明します。

「アラームを実行するデータポイント」は「M / N」の形式で設定しますが、これは

「直近N個のデータポイントのうち、M個(以上)で『条件』で指定した条件を満たしたら、アラーム発生させる」

というものです。（もちろん、データポイントは直近から過去のものを参照します)

例えば

  • 「アラームを実行するデータポイント」を「2 / 3」と設定
  • それ以外の設定は先程の画像の通り

で、実際のメトリクス値が下記の通りだったととすると、以下ように動作をします。(赤線がしきい値(=1)、緑線が実際のメトリクスの値とします)

  • 9:00～9:15分の間までは、直近3個で「メトリクス値が1より大きいデータポイントが1個より多い(≒2個以上)」状態が存在しないので、アラームは発生しない
  • 9:20の計測では直近3個で上記状態が存在する(9:20と9:10)ので、アラームが発生する

どんな時に便利？

「監視してるメトリクスの『状態』を監視する(=何か異常などがずっと起こり続けている)」際に便利です。

例えば単発のデータポイント監視だと、例えばたまたま一回だけなんかあった際にも、アラート発生します。

ただ監視内容的に、こういう「一回だけ何かあった」状態は問題ないとし、「継続的に何か異常が起こり続けている」状態だけ監視したい、という場合に役立ちます。(不要な調査作業を無くす、工数の有効活用、等)

(逆にいうと、これを適用して何かアラートが発生している場合は、間違いなく対抗必須な異常が起こり続けていることですが...)

本題：「欠落データの処理」について

で、本題の「欠落データの処理」です。

もちろんこれ自体は、「条件」ダイアログに記載の通り「欠落データを処理する方法(=欠落データをどう扱うか)」なのですが、単純に「欠落データがあった場合に『欠落データの処理』の方法で埋め合わせる」わけではありません。

CloudWatchアラームの仕様

CloudWatchアラームの仕様として、下記の仕様があります。

  • 直近N個の計測結果で判定する場合でも、実際にはN個より多くのデータ(=過去データ)を収集する
  • 収集したデータの合計がN個以上の場合、収集した過去データのみで判定を行う
    • 欠落データの埋め合わせは行わない

具体的な例を挙げて説明します。(アラームの条件は「前提：『アラームを実行するデータポイント』について」と同じとし、緑の●がない部分は欠落データとします)

過去データを含め、下記データを収集したとします。

上記のグラフで、直近3回のうち9:15と9:20はデータ欠落が発生しています。
しかし、収集した全データのうち、9:00と9:10、そして9:25のデータで「計測データ3個」の条件は満たせます。

この場合、欠落データの埋め合わせは行われず、9:00, 9:10, 9:25の3つでアラーム判定が行われます。(=「OK」と判定される)

では、いつ欠落データの埋め合わせが行われるのかというと、「収集した過去データを含めても、データがN個未満だった時」です。

欠落データの処理方法

実際の欠落データの処理には、下表の4つがあります。 仮に計測結果が下図グラフだった場合の結果も載せておきます。
※これもアラームの条件は「前提：『アラームを実行するデータポイント』について」と同じとします

項目 説明 備考 下図グラフでの結果
適正データとして処理 欠落した部分を「条件を満たさない」値として扱う OK
不正データとして処理 欠落した部分を「条件を満たす」値として扱う アラーム発生
見つからないのもとして処理 全データ欠落していた場合のみ「INSUFFICIENT_DATA」(=データ不足)状態にする(※1) 一部データのみ欠落の場合、存在する一部データのみで判定する(=条件を満たさないはずなので、OKになる？) OK
欠落データを無視 欠落データを無視し、存在するデータのみで判定する(=これも条件を満たさないはずなので、OKになる？) 全データ欠落時は、その時点の状態を維持する OK

※1：CloudWatchアラームの「通知」ダイアログにもある「データ不足」の状態です。

なお上記以外にも「早期アラーム状態」という、アラーム評価の特別なケースがありますが、これは説明が難しいので、アラーム評価の詳細説明と合わせて、下記AWS公式ドキュメントを参照してください。

参考：CloudWatch アラームの欠落データの処理の設定

常に直近N個の値で監視する方法(メトリクスMath&関数)

「欠落データの処理」に関しては以上ですが、先程CloudWatchアラームの仕様について

収集したデータの合計がN個以上の場合、収集した過去データのみで判定を行う(欠落データの収集は行われない)

と書きました。

これはこれで便利ですが、一方で「(データ欠落時に)直近N個の値でアラーム判定しない」ということでもあり、それはそれで問題になるケースもあります。(先程の例でも、「25分も前の状態で判定されても...」と思うかもしれませんし...)

そういう時に、必ず直近N個の値で判定する方法として用いられるのが、「メトリクスMath」のFILL関数です。

  • メトリクスMathは、一言で言えば「メトリクス値の計算に数式や(Excelワークシート関数のような)関数を使える」機能のことです。
  • ここでは詳細な説明は省略します。詳しくは下記AWS公式ドキュメントを参照

FILL関数の設定は、下記の手順で行えます。

  1. 「アラームの作成」→「メトリクスの選択」の「参照」タブから、元になるメトリクスをチェックする
  2. 「グラフ化したメトリクス」タブから、右上の「数式を追加」をクリックする
  3. 「数式を追加」から、「空の式で始める」をクリックする
  4. 「数式の編集」ダイアログが出てくるので、FILL(m1, 0)と入力して「適用」をクリックする。(「FILL」は大文字じゃないとダメ)

なおFILL関数は「あるメトリクスのデータが欠落した場合に、代わりの値を設定する」関数で、引数は以下の通りです。

引数 説明 備考
第1引数(=m1) 元になるメトリクスのID 今回はメトリクス「CallCount」のID「m1」を指定
第2引数(=0) 第1引数のメトリクスの値が欠落した場合に設定する値 実際はアラーム設定のより適宜値を変える

こうすれば、データ欠落は発生した箇所には値「0」が設定されるので、必ず直近N個の値でアラーム判定が行われます。

あと「ID」や「ラベル」はの値は変更可能なので、分かりやすい値に変更するとよいです。(名前右のアイコンをクリックする)

まとめ

以上、CloudWatchアラームの「欠落データの処理」についてでした。

私自身が「欠落データの処理」の仕様(というか、CloudWatchアラームの判定処理の仕様)について勘違いしていたので、今回改めてそれらについて知ることができてよかったです。

また、メトリクスMathや関数について、使いこなせば非常に便利そうだなあと強く感じました。

告知

まだ少し先ですが、来年2023年1月21日(土)に行われる「VS Code Conference Japan 2022 - 2023」で登壇することになりました。

vscode.connpass.com

登壇内容としては、Remote SSH(=VS Code拡張機能)について、以前書いた【VS Code】Remote SSHでSSH接続するの内容をベースに、もう少し深く説明したり、時間があればデモもやろうかなと考えています。

また何かあれば、公式サイトなどでも発表があると思いますので、よろしくお願いします。

では、今回はこの辺で＆よいお年を！