こんにちは。zozoフロントエンド部の大平です。さだまさし好きが昂じて社内では「さださん」と呼ばれています。
計測してますか？
皆さん計測していますか？
何かを改善しようとした場合、パフォーマンスを数値化し、その内容をもとに改善案を考えて行動することが、基本的な取り組み方になります。 そして、いかに現状を測定可能な状態にし数値化可能な指標を設定するか、という事が取り組みの第一歩になります。ダイエットや体質改善でもそうですし、英語など語学学習でもそうだと思います。
ということで、計測はとても大事です。
私事ですが、私は最近さだまさしさんのファンが集うコミュニティに参加しています。古くからのファンの方々はさだまさしさんのデビュー時からずっと追っかけている猛者も多く、私みたいな若輩者の青二才は圧倒的な「さだ力」の不足を感じる毎日です。
最近、コミュニティの中で「楽曲検定」というサイトが流行しました。このサイトではiTunesの試聴データを用いてアーティストの楽曲のイントロクイズを提供しています。
さだまさしさんは今年デビュー45週年を迎え、作った楽曲は550曲を超えると言われています。多すぎて覚えられないよとの一部ファン（私）のため息が漏れる中、2018年もまだ新曲を出す予定のようです。
そんな「ビッグデータ」を相手にしても、先輩さだファンは 「配信曲全て出題、間違ったら即終了 全曲編」 という鬼畜にも程がある問題を選択し、皆軽く全問正解していきます。無論私も全問正解するのですが、さだコミュニティの中では全楽曲を知っているのがベースラインとなり、「さだ力」を表現するKPIとして機能しません。
なので、最近はストップウォッチを片手にタイムトライアルを個人的に実施するようにし、日々の日課にしています。「さだ力」のKPIを楽曲数やクイズの正答数ではなく、 「MSPS (Masashi Sada Per Sec)」 においたわけです。
最初は普通のノートPCを使っていたのですが、時間を計測することによりトラックパッドによるマウスカーソルの移動に予想以上に時間を要している事に気づきました。
抜本的な改善のためには道具が必要ですので、Chrome OS/Android OSのハイブリッド利用が可能な Chromebook を導入し、画面のタッチパネルを使用する事により大幅に時間短縮を果たしました。
今では調子のよい時は「曲視聴~回答~次の問題選択」の一連の流れを1曲あたり2秒台（0.3~0.5 MSPS）で実現できるようになりました。しかしあまりに動きが速すぎるためかサイトがフリーズしてしまうことが頻発するようになってしまったのが悩みです。
Datadogについて
よくわからない事を書いてしまいましたが、ここから本論に入ります。
弊社内ではいくつかのサービスを開発運営しておりますが、サービスの安定稼働を実現するためにMonitoringツールを用いた監視を行っています。
各サービス利用しているツールは様々なのですが、私が現在担当しているシステムでは Datadog をメインの監視ツールとして使用しています。
ご存知の方も多いと思いますが、DatadogはNewYorkを拠点にサービスを展開しているいわゆるMonitoring SaaSです。日本においてはMackerelがMonitoring SaaSとしては有名ですが、Datadogはグローバルで使用ユーザーが多いサービスの1つとして知られています。
以下のグラフは、SRECon というイベントでのアンケート結果です。NewRelic などと拮抗して来場者の多くが使用しているツールであることが見て取れます。
Datadogの利点は数多いですが、ここでは私の主観でいくつかピックアップします。
豊富なグラフ表現とカスタマイズ性
Datadogの他のMonitoring Toolと比べたアドバンテージは、非常にリッチなグラフ表現をドラッグ&ドロップで簡単に実現できるところにあるかなと思います。 たとえば以下のようなDashboardを手軽に作成できます。
Slackとの連携が容易
現代的な開発エンジニアの間ではSlackなどのチャットツールがコミュニケーションのハブになっており、そこに情報を集約することが開発効率の向上や情報共有の円滑化につながります。
Mackerelなどでも同様の機能がありますが、DatadogではSlackなどに対してグラフ付きでメッセージやアラートを通知する機能をもっており、チーム内でのコラボレーションに非常に有益です。
豊富なAPI
DashboardやAlertingの設定は画面からでも行なえますが、Datadogは豊富なAPIを提供しているためそれらの操作をAPIを介して半自動化することも可能です。
よく使われている事例としては、Barkdog などのツールを用いたAlertingの設定のDSL化かなと思います。 Barkdogを用いると設定をGitHubなどで管理でき、差分管理やCIツールと連携した適用の自動化などを実現することが可能です。
Service Integration
豊富なService Integrationの機能もDatadogの魅力です。
AWS CloudWatchの情報や、NewRelicなどの他のMonitoring Toolの情報などを簡単な設定でDatadogに取り込む事ができます。この機能を用いることでDashboardの情報をDatadogに一元化することが可能になります。
また、Datadogの情報を入力ソースとして他のシステムと連携することもできます。代表的な事例は Pagerduty などのOn-Callツールとの連携です。Datadogのメトリクス内容を使用して特定の閾値に達したらPagerdutyのEscalation Flowに基いて障害通知を行う、といった事が実現できます。
Docker Integration
そして、最近は Kubernetes の流行などもあり、Docker/Docker Orchestration環境とMonitoring Toolの連携も必要になってきています。この辺については後段で詳しく触れます。
Kubernetes環境との連携
ということで、DatadogとKubernetesの連携について、AutoDiscovery機能を軸に少しだけ深掘りします。
たとえばKubernetes上にPodを展開すると、設定によってはAuto Scaling/Self HealingにてPod数がダイナミックに増減します。どのHost Computer上にどのPodが置かれるかは基本的にはKubernetesが管理することになり、人間が介在し事前に把握することが難しいです。
またDocker imageの中に必ず監視ツールを同梱する、もしくはSide-Car的に1対1で設置するというのも効率が悪いです。
ですのでMonitoring Toolは、何かしらの方法で現在動作しているPodの存在を自動的に把握し、監視対象とする仕組みが必要になります。
その仕組をサポートするものとして、PrometheusではService Discovery機能があります。これによりKubernetesクラスタ上に存在するServiceやPod、Ingressといったものの追跡が可能になっています。 https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3CKubernetes_sd_config%3E
同様に、Datadogには AutoDiscovery 機能があり、これによりPrometheusのService Discoveryと同様の機能を実現できます。
設定内容など詳しくは以下のQiitaに記事を書きましたので、こちらも参照ください。
Datadog の AutoDiscovery 機能を用いて自動的に Kubernetes pod の監視をする
現場では、以下のようなメトリクスについてAutoDiscoveryの機能を用いて取得しています。
- nginxのメトリクス (/nginx_status)
- Spring Bootのメトリクス
- Prometheus Exporter経由で取得できるようにしています
- Datadog を用いて Prometheus Exporter の監視をする
Docker時代/Kubernetes時代のMonitoring Toolには、このようなDiscovery機能が必須になってきていると思います。そして、Prometheus同様、Datadogはそういう時代の変化に追随しているサービスだなと感じており、組織の中でも重用しています。
STTクラウド技術共有会
少し話題が変わりますが、先日4月1日に会社が改組されたこともあり、これをひとつのきっかけに社内の技術者が組織を横断して集う情報の共有会を行いました。
技術分野は多岐に渡るため分科会的にいくつかの会を設けており、私はクラウド関連の技術についてディスカッションする会に参加しています。 先日開催された初回ではMonitoring Toolについてをテーマに開催されました。
どうしても監視周りはシステムの導入時期や担当エンジニアの嗜好なども影響します。そのため採用しているツールは各チームまちまちでしたが、その状況が共有できたこと、それぞれのPros/Consや導入の背景が理解できたことは良かったです。
とはいえ各チームとも以下については共通しており、同じ時代を同じ組織の中でともに歩むエンジニアとして、同じ方向性を見れていることを知れた事も有益でした。
- クラウドネイティブなツールを使って管理コストを減らしたい、というモチベーションが強い
- 設定はDSL化してGitHub管理している
- Slackへの通知など、コミュニケーションツールとの連携を重視している
このような会を定期的に開催し、各チームや各エンジニアの考えていることや取り組みを可視化しMonitoringすることも、とても大事なことだなと感じています。
まとめにかえて
Datadogについて、そしてMonitoringについてとりとめなく記事を書かせていただきました。
社内でよく話すのですが、Monitoringはひとつの手段でしかなく、目的ではありません。たとえば今回ご紹介したDatadogは本当によく出来たツールで、こちらにメトリクスを流し込んでグラフを作成しただけで何かしら言い知れぬ達成感・全能感があったりします。
しかし、技術者に求められているのは測定することだけではなく、 「システムをいかに安定稼働させるか」「そのためにいかにシステムの状況を正確に知るか」 にあります。
そして、Monitoringした内容等を基に 「仕事やサービスに対していかに効果的なアクションを取るか」 が、本当に求められていることです。
ついつい技術者は目の前の手段にとらわれがちですが、こういう意識を忘れずに、日々サービスを改善をしていければと思います。
私が「さだ力」を向上したいと思っているのも 「えー、さだまさしの事そんなに詳しいんだ、すごーい」 と女の子にキャッキャウフフともてはやされることが目的ですので、本来のゴールを見失わないよう日々慎ましく生きていきたいと思います。
[AD]
弊社では、さだまさしに対する愛情は必ずしも必要ないですが、情熱をもってサービスを支えるエンジニアを募集しております。
ブログでの情報発信の他に、弊社では月一回のペースでMeetupイベントなども開催しております。皆様との交流を通じて、我々の行っている取り組みや、我々のサービスにかける思いを知っていただく場をもっと増やして行こうと考えておりますので、ご興味を持たれた方はぜひぜひご参加いただければと存じます。
