こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 プロダクトの規模が小さいと1人 SRE という体制は珍しくないと思います。 1人で何が辛いかというと、相談相手やレビュー相手がいないことです。ですので、最近は AI/LLM に相手をしてもらっています。 運用に使っている Lambda 関数や Terraform のコードをレビューしてみたり（※1）、エラー発生時の1次対応をお願いしてみたり（※2）しています。 ※1 プルリクしたら Bedrock にコードレビューしてもらいたい ※2 AIOps入門 AWS Bedrock で障害分析 私は毎朝のタスクとして、ダッシュボードチェックを行っています。 平日なら前日分、土日祝日なら2〜3日分のメトリクスを眺めながら、異常な挙動はないか、パフォーマンス劣化が起き

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 オブサーバビリティの基盤を用意することは簡単ではありません。(難しくもありません) そして、それを運用していくコストも考えなければなりません。顧客向けのサービスではないので、導入するにあたりプロジェクトオーナーを説得できない場合もあるかもしれません。 それが CloudWatch の画面だけで完結するとしたら素敵なことですね。 Grafana も Prometheus も Jaeger も要りません。CloudWatch だけです。 デモ Docker compose で Application Signals を体験できるデモを作りました。このデモを触りながら Application Signals の機能を理解していきましょう。 構成は以下になります。

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 なにごとも小さく始めて成功体験を積み上げながら大きくしていくのが良いと思います。 Observability についても同じ考えです。 これから Observability を導入する方の助けになればと思い、ECS で小さく始める OpenTelemetry 構成をご紹介します。 構成 アプリケーションに OpenTelemetry SDK を組み込み、トレースとメトリクスを OpenTelemetry Collector に送信します。 アプリケーションのログは CloudWatch Logs に送信します。 OpenTelemetry Collector はサイドカーを選択肢しました。 OpenTelemetry Collector は Tempo に

分散かつ複雑化するアプリケーションの内部動作を把握するためには、伝統的なメトリクスによるモニタリングやログの egrep だけでは不十分です。 オブサーバビリティの概念を取り入れ、予見しない状態に変化したときにもアプリケーションの内部動作を把握し、早急な回復を行う準備を整えることが求められます。 オブサーバビリティを実現する方法は多くありますが、その中でも OpenTelemetry はオープンソースでベンダー非依存のプロジェクトとして注目されています。 この本は OpenTelemetry をこれから始めるエンジニアに向けて、基礎を学ぶ入門書として活用していただくたい思いで執筆しました。 この本で書く内容は OpenTelemetry の基本となっています。詳しく知りたい方は公式ドキュメントを参照してください。 https://opentelemetry.io/docs/

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 DMARC 対応していますか？ メール管理者の方々の苦労が目に浮かぶます。DAMRC レポートを受け取ってチェックするといった作業がしばらく続くことと想像します。 ただ、xml を解析するのは生産性が低い作業だと思います。少しでも楽をしたいと思います。 parsedmarc 今回は parsedmarc を使います。 parsedmarc は OSS の DMARC レポート解析と可視化ツールです。 xml 形式の人間には読みにくい DMARC レポートを読みやすく可視化してくれます。 私は試していないですが、IMAP 等でメールを読み込み、自動で解析してくれる機能もあるようです。 parsedmarc は Grafana と Elasticsearch

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 最近のアプリケーションは分散が当たり前になりました。Ops に関わる人間として思うことは、従来のログとメトリクスだけ取得している監視ではエラー時の対応が難しいということです。 何らかの APM を導入して追跡可能な状態にしておくことが必須です。 ということで、今回は AWS Distro for OpenTelemetry (以下、ADOT) を試してみました。 ADOT とは AWS がサポートする OpenTelemetry のディストリビューションです。 アプリケーションのメトリクスやトレースなどを収集し、バックエンド (AWS サービスやサードパーティ) へ送信する仕組みを提供します。 また、AWS リソースやマネージドサービスとの親和性が高く、こ

AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 Mountpoint for Amazon S3 が発表されました。 Linux から直接 S3 バケットに対して読み書き機能を提供するソフトウェアです。細かく書くと、読み取りと新規ファイル作成を行うものです。 データレイクからファイルを読み取り何らかの処理をして結果ファイルをデータレイクへ戻す、みたいな処理に適切です。 処理をするアプリケーションによっては S3 API をネイティブにサポートしていないことは珍しくないはずで、その際は前後に S3 Get/Put する別処理が必要でしたが、Mountpoint for Amazon S3 によってファイルシステムとしてマウント可能になれば別処理は要らなくなります。 ただ、S3 はオブジェクトストレージであ

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 ちょっとした衝撃を受ける発表がアメリカ時間の2023年7月28日に AWS がありました。 2024年2月1日よりパブリック IP アドレスに時間あたりの課金が発生するようになります。 従来は使っているインスタンスに紐付いたパブリック IP アドレスには課金が無く、使っていないものだけの課金でしたが、2024年2月1日以降は使っているかどうかに関わらず課金されます。 課金は 0.005USD/Hour になっています。 0.005USD/Hour * 24h * (28|29|30|31)days * インスタンス数 の計算式で増加分が計算できます。 対応作業 月曜日の朝に出社してアナウンスを見てからやることを考えました。 やる前からインパクトが大きくなる