導入事例:株式会社一休 | Datadog
CASE STUDY

リアルタイムな統合モニタリングで、
エンドユーザーが気づく前に問題を解決

株式会社一休

株式会社一休は1998年設立、上質 なホテル・レストラン予約サイト 「一休ドットコム」などを運営す る企業。バリューとして掲げてい るのがユーザーファースト。施設 の利用客を最優先に考えている。 サイトが案内する施設を通じて 「こころに贅沢」な時間を世に増 やすことを目指している。


主要成果

問題対処を迅速化

プロダクト開発が責任をもって 運用までおこなっている。イン フラや外形監視でほぼリアルタ イムで通知を受け、APMで問題 解決とシームレスに対応ができ るようになった。

デプロイが10倍以上に

2週間に1度だったデプロイを Datadog導入とともに自動化を 進めた結果、1日数回へと大幅 に頻度を上げられた。

課題

メトリクスやログなど あちこ ちに情報があり、障害が起き たときにどこに問題があるの か職人技で探さねばならなか った。

リリースのタイミングでパフ ォーマンスが落ち、サイトが タイム・アウトしてユーザー から見えないことがある。DB に対するクエリータイムアウ トやそれ以外の再帰呼び出し の多発などいろいろなケース がある。以前だとクエリーが 悪いのではないかとかロジッ クはどうかとコードレビュー するなど試行錯誤が必要だっ た。

なぜDatadogか?

システムのクラウド移行に伴 い、SaaS型で運用負荷が少な い監視ツールを探したところ、 Datadogが目についた。メト リクスが豊富で、ダッシュボ ードから必要な情報を一覧で きて、Slackとの連携しやすい さなどが魅力だった。

本気のエンドユーザーファーストを支える

ビジネスの都合でなく、お 客様が欲しい情報をうまく 出していきたい。常に期待 に応えられるよう基盤が安 定していることが大事。


メトリクスやログの情報が散在していて問題解決が迅速にできない

一休が運営する「一休.com」は厳選されたホテルやレストランの 予約サイト。施設の事業者と利用客を仲介するB2B2C型のプラッ トフォームとなる。また、一休はトラベルWEBマガジン「一休コ ンシェルジュ」、プレミアムな店舗を紹介するグルメメディア 「KIWAMINO」も運営。2007年からはYahoo!トラベルと本格提携 が始まり、今では所属するZホールディングス全体に事業範囲を広 げている。

Datadogを通じて監視するサーバーは300台以上。ほとんどがAWS EC2で、ごくわずかにオンプレの機器が混じる。なお一休では、プ ロダクト開発が運用も責任を持つような体制としているのが特徴だ。

一休.comでの宿泊予約サービス開始は2000年から。旅行のオンラ イン予約サイトとしては先駆けと言える。利用者数増加に応じて規 模拡大を続けてきたが、クラウド移行してDatadogを導入する前ま では、テレビで有名人がサイトで掲載しているホテルやレストラン を話題にした途端、サイト負荷が急増してサイトごとダウンという ような問題も経験してきた。

社内のインフラ監視では問題がなくてもユーザーが使えない状態が 発生し早期に気づけないことが課題だった。

「システムの健全性を把握するために必要な情報(メトリクスやログ)が散在していたため、異常発生時には複数のツールにまたがり原因を探す必要があり、職人技と運が必要でした。また、リリースのタイミングでパフォーマンスが落ちることがあり、クエリーやロジックをレビューするなど試行錯誤していました」

株式会社 一休
CISO 兼データサイエンス部 部⻑ 兼CTO室 エンジニア
植竹 剛人 氏

リリース後に起きる性能低下の原因究明と対処に

Datadogを導入すると、まずは本番環境全体におけるメトリクス監視から 着手した。あらゆるインスタンスのメトリクスを単一の画面で確認できる だけではなく、社内の連絡手段となるSlackとの親和性が高いため、 Datadogは社内で普及していった。

植竹氏は「Datadog導入以来、エンジニアの共通認識としてDatadogのメ トリクスを見るようになり、業務の一部として馴染んでいます」と言う。 今では50〜60人のエンジニアがインフラのメトリクスを習慣的に見るよう になっている。

異常のアラートはSlackチャンネルに集約し、必要なメンバーに通知して いる。例えばCPUの使用率がしきい値を超えたら、通知に直近のグラフを 添付することもできて「分かりやすい」と評判だ。異常の通知があれば担 当者がDatadogを見て解決するというフローが生まれている。

リリース後にパフォーマンス低下などで、ユーザーがサイトにアクセスで きなくなることがある。原因はデータベースへのクエリータイムアウトや、 再帰呼び出しの多発など、様々なケースがある。かつてはリリース後に不 具合が起きると、クエリーやロジックに問題がないか確認するのに手間が かかっていた。しかしAPMを見れば、時間がかかっている場所が一目瞭然 となるため、リリース後に起きた問題の原因究明が素早くできるようにな った。植竹氏は「手慣れたエンジニアでなくても原因が分かり、『これな ら切り戻したしたほうがいい』などと対処を判断できるケースが増えまし た」と話す。

Datadog導入で運用やデプロイも変化した。かつては運用専任者がいて、 デプロイフローが自動化されていなかったため手動でデプロイしていた。 差し戻しがあると、かなりの手間となっていた。後にGitHubやCircleCIな どの環境を整え、同時にDatadogのモニタリング活用で開発が運用にも責 任を持つ体制へと変えることができたため、デプロイの効率化が進んだ。 かつてデプロイは2週間に1度だったが、今では1日に数回の高頻度へと変 化した。

サーバレスへの移行もDatadogで安心

導入から約6年。今ではDatadogは一休.comの状態監視、異常時の通知、 外形監視、ログ基盤、異常検知、社内システムのネットワーク機器監視 にも広げて活用している。

今後について植竹氏は「現在はサーバーレス(AWS Lambda)や Kubernetesへ徐々に移行しているところです。Datadogならコンテナに も簡単に導入できるので安心です。新しい環境にマッチしたモニタリン グをきちんとしていきたいです」と話す。

また期待するところとして、植竹氏は異常検知の高度化を挙げる。イメ ージとしてはより賢いアノマリーだ。Watchdog機能から通常と異なる 動きをフィード形式で確認できるため植竹氏は「今後使いこなしていき たい」と高い関心を持っている。

植竹氏は「一休としてはお客様に満足してもらえるように欲しい情報を もとにうまく出していきたい。常に期待に応えられるようスケールし、 基盤が安定していることが大事です」と語る。

リソース