Lyftと運用ログ：Splunk CloudからAmazon ES、セルフマネージドのElasticsearchへ

本記事はElastic{ON} 2018での事例紹介セッションの要約です。Elastic{ON} 2018のセッションはアーカイブで多数公開中です。また、お近くの都市で開催されるElastic{ON} Tourのスケジュールもご覧ください。

年間数億回（2017年は3億7千万回超）の乗車を取り扱うサービス事業者のLyftには、すべての乗客を確実に目的地に運ぶためのパワフルな技術インフラが欠かせません。2017年現在で、1万を超えるEC2インスタンスから200以上のマイクロサービスを提供しており、その数字は大晦日（1日あたり200万回の乗車）やハロウィン（ピークで毎分2000回超の乗車）にはさらに増加します。Lyftのすべてのシステムと乗車サービスを安定稼働させる上で重要となるのが、エンジニアにすべての運用ログへのアクセスを確保すること。そのため、マイケル・ゴールズビー氏と彼が率いる可観測性チームはログパイプラインのサービスフローを昼夜保ち続けています。

ログ分析の開始時、LyftはSplunk Cloudのサービスを使用していました。しかし、ピークタイムでもバックアップデータ投入が30分間隔という制約があったこと、スケールする際にコストがかさむなどの理由から、Elasticsearchを導入することとなりました。

2016年の終わり、2人のエンジニアが1か月限定で、Splunkに代わりAWSでAmazon Elasticsearch Serviceを試験運用しました。この結果、Elasticsearchは非常に良かったものの、AWSのサービスはLyftにマッチしない部分がありました。ゴールズビー氏のチームが当時の最新バージョンであるElasticsearch 5.xを希望したのに対し、AWSで提供されていたバージョンが2.3であったことが理由の1つです。さらに、Amazon EBSのストレージでは新規のインスタンスに制限があり、Lyftに最適な規模へスケールさせた場合、パフォーマンスと信頼性を確保できないという問題もありました。しかし、こうしたAWSの制約を考慮しても、Elasticsearchへの移行にはメリットが多くありました。

バックアップデータを投入する間隔の制約から解き放たれたことで、運用監視チームは新しい扉を開くことができました。つまり、「全部のログを送る」という新たなアプローチを実現させたのです。データ投入のレートは毎分100Kイベントから1.5Mイベントにまで跳ね上がりましたが、4か月ほど、すべてが順調に進みました。しかし、次第に投入のタイムアウト、保存期間の短縮、Kibanaダッシュボードの反応遅延などの問題が生じるようになります。スケールの不足から来るものでした。当時AWSの上限は20ノードでしたが、Lyftは例外として特別に40ノードを使用させてもらえることになりました。

その40ノードでも問題が生じるようになりました。いわゆる「レッドクラスター」です。

ゴールズビー氏のチームは、クラスターのヘルスが「レッド」になった際の対処方法も心得ていました（リスタートする、ノードをリプレースするなど）。問題は、クラスターに直接アクセスできないことでした。AWSを運営するAmazonでサポートチケットをオープンし、ビジネスがピークとなる時間帯でもサポートからの応答を待ち続けるしかありません。また窓口となる担当者にはクラスターへのアクセス権がなく、サポート内でエスカレーションが行われます。Lyftはこのプロセスを学び、アクセス権のあるAmazonのテクニカルアカウントマネージャーに直接連絡をとるようになりました。

外部サポートの問題や、バージョンが2.3であること、EBSの要件のほかにも、均等負荷分散、60秒のタイムアウトルール、API機能の制限など、LyftがAWSにマッチしない部分は少なくありません。こうして運用監視チームはふたたび移行を決意し、今度はセルフマネージドでElasticsearchをデプロイすることにしました。ゴールズビー氏は次のように語っています。「（当時のAWSでは）使える機能にも制限がありました。社内でElasticsearchの運用経験がある程度蓄積されてきたこともあり、今なら自分たちでやれると考えたのです」

LyftはSplunkの導入時よりやや大きなチームで取り組み、セルフマネージドのElasticsearchへの移行をわずか2週間で実現しました。すべてのデプロイを自分達でできるようになり、AWS時代にはなかった機能も使えるようになりました。またこの瞬間から、クラスターをグリーンに保ち、ユーザーに快適なサービスを提供することを含めて、Elastic Stackのオペレーションの全責任をLyftが負う体制となりました。

Elastic{ON} 2018で発表された事例紹介セッション「運用ログ分析のためにセルフマネージドのElasticsearchに移行したLyftの軌跡」も併せてご覧ください。ハードウェアの選択やインデックスライフサイクル管理など詳しい設定情報のほか、「すべてをログにする」ことと「何でもログにする」ことの違いについても紹介しています。