Table of Contents
Great systems are not just built. They are monitored.
MetricFire runs Graphite and Grafana as a fully managed service for growing engineering teams, taking care of storage, scaling, and version updates so your team doesn't have to. Plans start at $19/month, billed per metric namespace rather than per host, and include engineer-staffed support. Integrations work natively with Heroku, AWS, Azure, and GCP, and data is stored with 3× redundancy in SOC2- and ISO:27001-certified data centres.
はじめに
MetricFireでは、エンジニアの方々と、技術スタックやSREの課題、インフラ監視への取り組み方について意見交換を行うことに大きな価値を見出しています。先日、ラテンアメリカのクラウドコンサルティング企業に所属するYoimer Roman氏と対談する機会を得ました。同氏は、AWS CloudWatchの監視機能を活用して、クライアントがより賢明なビジネス判断を下せるよう支援しています。Roman氏は、AWSに関するあらゆる面でチームを指導したり、カスタムクラウド環境を設計したり、技術的な課題と非技術的なステークホルダーとの橋渡し役を務めたりと、多岐にわたる役割を担っています。彼は、モニタリングやオブザーバビリティ、そしてあらゆる規模の企業でAWSを効果的に活用することに情熱を注いでいます。
監視分野に精通していて、ノウハウを共有したいという方がいらっしゃいましたら、ぜひお知らせください!皆様の取り組みについてお聞かせいただければ幸いです。
CloudWatchをどのように活用しているか
Roman氏は、自社で複数の顧客向けにオブザーバビリティを管理し、AWS環境をプロアクティブに監視しながらコスト削減を支援しています。彼はCloudWatchベースの監視ソリューションを構築し、顧客インフラに対する深い可視性を提供しています。その主な目的はコスト最適化です。彼らの目標は、顧客が自身のインフラを理解し、より賢く費用対効果の高い意思決定を行えるよう支援することです。顧客の中には高度な技術知識を持たない人もいるため、Roman氏はAWS CloudWatchを活用して重要なメトリクスを監視し、必要以上の費用を支払わないようにしています。
対話の中で、CloudWatch、EC2、RDS、Lambda、ALBについて取り上げましたが、これらはいずれもRoman氏が高い専門性を持つ分野です。彼はコスト削減戦略の発見に注力しており、障害が発生するまで待つのではなく、プロアクティブなアプローチを採用しています。自動アラートやコストしきい値を設定することで、チームが異常を検知し、効率的にリソースをスケールし、問題が発生する前に不要な支出を防げるようにしています。また、Terraformを活用してアラームを自動化し、監視ワークフローを効率化しています。
「とても簡単です。EC2インスタンスプロファイルにCloudWatchポリシーを追加するだけです。例えばCPU使用率メトリクスを監視したい場合、それだけで十分です。そのメトリクスのしきい値を設定すればアラームを生成できます。そしてCPU使用率がそのしきい値、例えば80%を超えると、最終的にAWS EventBridge経由でアラームが発火します。その後、その情報を好きなように活用できます。私たちはそれをLambdaで処理し、自動的にSlack通知を生成しています。」
アラームとスケーリングの自動化
インフラ管理を簡素化するために、Roman氏はTerraformを使用してCloudWatchアラームとスケーリングポリシーを自動化し、複数のAWSアカウントに監視を簡単に展開できるようにしています。彼のTerraformテンプレートは、ALBターゲットグループ、EC2監視、Lambdaしきい値を管理し、手動設定を減らしながら一貫性を維持しています。さらに、TerraformのstateファイルをS3に保存することで、顧客環境を中断することなくスムーズにインフラ更新を行えるようにしています。すべては効率性を高め、AWS監視を可能な限り手間のかからないものにするためです。
「ベストプラクティスとして重要なのは、プロアクティブ監視です。私は、深夜3時に顧客から『サービスが停止しており、お金を失っている』という電話を受けるまで待ちたくありません。顧客のコアビジネスや収益構造を理解し、それを重要な技術的監視メトリクスへ落とし込む必要があります。もしSQSを使っていたり、キューを管理していたり、Kinesisでデータ分析を行っているなら、それら重要コンポーネントをリアルタイムで監視するようにします。継続的でプロアクティブな監視こそが、すべてをスムーズに動かし続ける鍵です。」
Terraformによって効率性は向上するものの、一部の顧客は手動でのAWS設定を好むため、自動化と従来型ワークフローのバランスも必要だと彼は認識しています。彼のコスト最適化戦略には、CloudWatchログの分析、利用率の低いリソースの特定、インスタンスタイプ変更によるコスト削減が含まれています。また、AWS Savings PlansやReserved Instancesを活用し、パフォーマンスを維持しながらAWSコストを削減しています。このアプローチにより、監視はプロアクティブかつ自動化され、スケーラブルなものになります。
IoT、AWS、FreeRTOSに関する経験
AWSエキスパートになる前、Roman氏はIoT開発からキャリアをスタートし、ESP32マイクロコントローラーとAWS FreeRTOSを扱っていました。彼はFreeRTOSを利用して、温度、湿度、気圧、GPSトラッキングなどのセンサーデータを収集し、それをMQTT経由でAWS IoT Coreへ送信していました。これにより、デバイス管理が大幅に容易になりました。
大規模なデータ取り込みを処理するために、彼はRaspberry PiをIoTゲートウェイとして構成し、データをDynamoDBへ送信していました。IoT分野における大きな課題の一つはファームウェアアップデートですが、Roman氏はS3バケットを利用したOTA(Over-the-Air)アップデートを実装し、さらにアップデート失敗時に安定版ファームウェアへ戻すロールバック機構まで構築しました。
そして全体を統合するために、彼はフロントエンド開発者と協力してインタラクティブなダッシュボードを構築し、デバイス位置のマッピング、リアルタイムのステータス表示、接続が失われた際のアラート発火を実現しました。このプロジェクトは、組み込みシステムとクラウドインフラを橋渡しするものであり、Roman氏がハードウェア、クラウド、自動化を組み合わせてシームレスなデバイス監視ソリューションを構築できることを示しています。
MetricFireのHosted Graphiteプラットフォームを探る
AWS CloudWatchのコスト上昇を受けて、Roman氏はMetricFireのHosted Graphiteのような、よりコスト効率の高い監視ソリューションを検討し始めました。彼が特に注目しているのは、MetricFireのパブリックインジェストエンドポイントです。これにより、複数ソースからのデータを簡単に集約できます。一方AWSでは、メトリクス数やデータ取り込み量に応じてコストが急速に増加する可能性があります。CloudWatchがAPIコールベースの料金体系であるのに対し、MetricFireは保存されるユニークなメトリクスネームスペースに基づいて課金されるため、大幅なコスト削減が期待できます。MetricFireはCloudWatchからデータを取得し、それをGraphiteメトリクスへ変換して効率的に保存します。そのため、ユーザーはCloudWatch APIを繰り返し呼び出すことなく、自由にデータをクエリできます。
「私はAWS Budgetsを使っています。例えば2週間後に予算全体が、たとえば35Kを超えたらメール通知を受け取ります。あるいは、毎日500ドル消費している場合にもアラートが届きます。そこから私はコスト最適化を深く掘り下げます。未使用インスタンスの削減、Savings Plansの導入、Reserved Instancesの利用などです。しかし、本当の意思決定は監視から生まれます。CPU、メモリ、ネットワークトラフィックを監視することで、パフォーマンスに影響を与えずにインスタンスサイズを縮小できるか判断できます。監視こそがコスト効率を生み出します。」
彼はまた、MetricFireがCloudFormationテンプレートや過剰な権限を必要とせず、使いやすいインターフェースを提供している点も評価しています。そのため、既存のAWS環境への統合が容易です。CloudWatchは依然として強力なツールですが、監視コストが高額になっている企業にとっては、より予算に優しい代替手段へ切り替えるメリットがあるかもしれません。もしMetricFireが特定のワークロードに対して有効な代替となるなら、Roman氏はより広範なAWSコスト最適化戦略の一環として導入することに前向きです。
まとめ
Roman氏のAWSモニタリングへのアプローチは、自動化、コスト最適化、そして予防的なアラート通知における模範的な事例と言えます。CloudWatchを活用したモニタリングやTerraformによる自動化から、インフラの効率的なスケーリングに至るまで、彼は企業が莫大なコストをかけることなく、必要なインサイトを得られるよう支援しています。IoTモニタリングにおける彼の経歴は、組み込みシステムとクラウドを統合する能力を物語っており、また、メンターとしての活動を通じて次世代のAWSエンジニアの育成にも貢献しています。
AWS以外にも、Roman氏はMetricFireのような監視ソリューションを含め、コストを最適化し可視性を高める新たな方法を常に模索しています。CloudWatch、Terraform、あるいはその他のプラットフォームを問わず、彼の焦点は一貫しており、企業が予算内で事業を運営し、潜在的な問題に先手を打てるよう、信頼性が高く、スケーラブルで、コスト効率の良い監視ソリューションを構築することにあります。