アドオンを自作する方法を見てみた」でした。帰ってきてすぐにHerokuの記事書いて...となかなか精力的なエンジニアっぽい感じですが、肩書は社長です。使いはじめてから気づく魅力の一つに、標準で用意されている機能の豊富さが挙げられます。CIでのCI/CD、CLIやAPIなどなど...マネージドという言葉でIaaSプラットフォームもたくさんの機能を複雑な設定なく利用できるようになりましたが、開発者がプログラミングに集中する、それを実現するための万全な体制をプラットフォームが引き受ける。作り上げてきたものです。同じ考え方の元で用意された標準機能の一つと考えられます。ほとんど導入コストなしに、アプリケーションのパフォーマンス監視ないし必要に応じた通知を行える機能です。DynoやAddonのPlanを柔軟に変えられるためか、Metrics自体の機能をそのまま使わずにカットオーバーを目指しているプロジェクトを見かけることがあったので、どういうことができるんだろう・ひとまず使ってみましょうという思いから今回の記事を作成しました。よるモニタリングレポート。CloudWatchのダッシュボードに近いと思いますが、エージェントを設定したりダッシュボード自体を作る必要はなし。いくつかの手順を踏むだけで使えるようになります。以下は、いくつかのダッシュボードの例です。管理者用サイト、マイページのデモサイト、ショッピングサイトと用途はそれぞれ。言語の違いによってもある程度これらの数値は変わってきます。いずれにしても、アプリケーション開発者はほとんど何も実装や設定をせずに使い始めることができます。メトリクス以下のメトリクスが見られます。見ながら、それ以外のメトリクスの動き方をじっくり眺めるのが良いんじゃないかと思います。以下も追加で閲覧可能。情報が表示されるようになります。上の選択リストで対象のDynoを選択。メトリクス期間の選択こちらの選択リストでメトリクスの期間を選択します。選べるのは「過去2時間/過去24時間/24~48時間前/48時間前〜72時間前/過去3日間/過去7日間」のいずれか。15ヶ月くらいだったと思いますが、稼働中だったりサービス稼動目標があるアプリなんかだとよほど遡及せざるを得ない理由が無い限り、そこまでの期間は必要ないですね。歯車アイコンからメトリクスの設定が可能で、ダッシュボードの見た目だったりRuntimeごとのメトリクスをここで有効化します。様子を見ていればいつの間にかメトリクスに上がってくるようになります。Requestsについてはしきい値を設定して、超えた場合にメール通知を行うことも可能です。一度渡してポリシー適用というのが可能です。投げ先としては運用チームのメーリングリストなり、SlackのEmailAppを設定済みの監視Channelなりを選ぶのがシンプルだと思います。注意したいのは、Addonをいくつか使っていると通知系が渋滞気味になるので、ちゃんと通知系の設定の粒を揃えておくべきということです。NewRelic/PagerDuty/Bugsnag/PapertrailとHerokuMetricsでそれぞれ通知の系があるのであれば、通知やサマリー送付などの頻度・条件を揃えておくか、ひと目でわかるように一覧化しておきましょう。時間差があると障害対応時に錯綜することがあるので。本番の稼動監視アプリケーションの運用保守用途に使います。設定先としては、上に挙げたような、監視用MLへの通知、Slackへの通知。時間間隔は「1分/5分/10分」から選べますが、連携システムがある場合はそちらに合わせることが多いです。AWS側が詳細モニタリングを有効化しているなら、1分に合わせたり、など。Throughput。本番稼働後というよりは設計/実装時のサイジングの検証時に見ることが多いです。みながら、問題箇所を特定していきます。ポイントとしては、プラットフォーム/アーキテクチャレイヤーでの解決が可能かどうかの切り分けをすること。DynoやAddonのPlanを変えてもエラーが出続ける場合は、ソースコードのロジックに何か問題がある場合があります。役割分担ができるので、そこまで大変ではないと思います。特定用途で結構Gem入れちゃってたりすることもあると思うので、うまい棲み分けが正直知りたいところ。非機能系テスト用パフォーマンステストと監視テスト、障害復旧テストあたりで使います。stagingまたはtest用環境を用意して、本番想定の状態でテストを行い、しきい値が適切か、きちんとアラートが飛ぶか、または通知後の復旧手順が正しく踏めたかを検証する際に利用します。必須ではないと思います。拡張性や柔軟性の高さから、順次考えていけばよい、その時に設定すれば良い、という考え方もできるので。比べて少し変わってくるかなと思ってます。縁の下の力持ちな存在として、Herokuでのアプリケーション運用を支える重要なサービスであり、黒川が書いたようにHerokuを使う価値をわかりやすく体現した存在であると思います。簡単に使い始められるので、ぜひ使ってみてください。はじめにはじめまして、フレクト代表取締役の黒川です。フレクトはHeroku、Salesforce、AWSのパートナーとして、IoTやAIなどデジタルサービスの構築をご支援しているマルチクラウド・インテグレーターです。B2Bのリアルタイム車両管理「Cariot」をSaaSで提供していてます。Herokuは2012年から利用していて、当時、TV番組連動のWEB・モバイルサイトを3週間の短期間で、かつ高い性能要件を満たしてリリースできたのは、Herokuだからこそ成せる業として社内で語り継いでいます。(語り継がれているわけではありません。)またオフィシャルな「Heroku実践入門」のトレーニングカリキュラムの作成や講師も担当していました。(途中からSalesforce社にバトンタッチして今はやっていません。)もちろん現在でもHerokuを広く活用している会社がフレクトになります。HerokuとAWSさてそんなフレクトでも現場においてHerokuとAWSの選定は議論になるところです。案件においてSalesforceのインテグレーションがあればHeroku、顧客の指定があればそちらのクラウド、またHerokuもAWSも適材適所で使い別けてマルチクラウド環境で組み合わせをするといったことも多々あることです。AWS」セッション資料を引用しながらご紹介します。言わずもがなではありますが、HerokuはAWS上で提供されているPaaSです。多くのAWSサービスをHerokuも利用しています。2018の期間中だけでもAWSのサービスリリースは100以上もありアップデートがすこぶる早いです。全てのサービスを抑えることは困難ですが、部分的でも最新のサービスをキャッチアップし続けることは、それはそれで大変です。そもそもAWSを利用する際は、インフラ設計・実装ができるリソースが必要になります。等々Herokuは開発・運用におけるエンジニアのリソースをアプリケーション開発に注力することができる、また生産性を高めることができる環境と言えます。2018期間中に、縁(訳?)あってBiz側の人間ながら記事投稿させていただくことになりました。Tech内容ではありませんが、ご容赦ください。〜色づくラスベガスのDay4から〜Cariot事業部の遠藤です。今日はいよいよ大詰めとなる4日目のレポートです。3はじめまして、CI事業部の金子です。