2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
司会者:よろしくお願いいたします。みなさん拍手でお願いいたします。
渡邊紘太朗氏(以下、渡邊):では「LINEデリマでのElasticsearchの運用と監視の話」というタイトルで発表を始めさせていただきます。よろしくお願いします。では始めに、簡単に自己紹介をさせていただきます。開発3センター開発支援室という部署に所属しています、渡邊紘太朗といいます。
2016年の4月に弊社へ転職してきたんですが、それまではアプリケーションエンジニアをしていて、転職を機にサーバーサイドのエンジニアからインフラエンジニアに転身をしました。
現在は今回紹介するLINEデリマを始めとしたLINE LIVE、LINEポイント、LINEギフト、LINEマンガ、Clova、これらのサービスの開発支援の担当を行っています。ここに記載されているサービスは開発3センターの中でみているサービスの一部なんですが、ほとんどのサービスが検索エンジンとしてElasticsearchを利用しています。
では次に本日のアジェンダですが、まずはじめにLINEデリマというサービスについて説明させていただきます。そのあとにElasticsearchの運用について、監視について、今後の展望について。最後に質問で終了したいと思います。
LINEデリマ、まだサービスがリリースされてから日が浅いサービスなので、LINEデリマで利用しているElasticsearchの運用と監視について、ポイントを押さえながら時系列で説明することでLINEデリマの生い立ちを理解していただく、ということをゴールに設定して話を進めていきたいと思っています。
まず始めにLINEデリマについて説明します。
LINEデリマは、2017年の7月26日にリリースされた、LINEと夢の街創造委員会株式会社が提携をして展開している、フードデリバリーサービスになります。現在はLINEアプリ内からこのLINEデリマのページに飛ぶことができます。
またLINE公式アカウントとして@limedelimaというアカウントがあり、こちらで割引情報などのお得な情報を配信しているので興味のあるかたはぜひ登録してみてください。LINEデリマではElasticsearchを検索エンジンとして利用しております。
勝手な想像ですが、この後の懇親会もLINEデリマで注文した商品が来るものだと思っております。
スタッフ:違います。
(会場笑)
渡邊:とのことです。
こちらがLINEデリマの検索部分における全体像になります。
LINEデリマはSPAとして実装されていて、トップページにアクセスするとAPIサーバーに対してリクエストを行っております。APIサーバーはElasticsearchクラスタに対してリクエストを行い、結果を返しています。このAPIサーバーからElasticsearchへのリクエストに関してはLBなどを経由してはいません。
次に、データのインデクシングについてですが、LINEデリマはマスターデータのために2つのバッチサーバーが稼働しています。1つめは夢の街創造委員会が管理する商品データ、店舗データ、地域データといったデータを社内のDBにシンクするためのバッチサーバーです。
2つめは、そのシンクしたデータを社内のElasticsearchにインデクシングするためのバッチサーバーになります。インデクシング用のバッチサーバーはこれらのインデックスに対して数分おきにインデクシングを実行しているというような感じになっています。
では次に、リリース時のElasticsearchのクラスタについて解説していきます。
リリース当初は3台の物理サーバーでクラスタを構築していました。このなかで、マスターノードが1台、データノードが2台として稼働していました。Elasticsearchを利用された方がいるのであれば、これを見て問題に気づくかもしれないのですが、ここからはこのクラスタを改善していく話になります。
さらにその他の構成要素です。
LINEデリマはJavaで書かれたアプリケーションなので、JavaのクライアントとしてTranspoetClientを利用しています。地域データであるblock、商品データであるitem、店舗データであるshop、の3つがインデックスとして存在しています。
また、ダッシュボードとしてはサードパーティのcerebroを利用していまして、動的な設定値の変更はこのダッシュボード上から行うようになっています。
それではここまでの情報を踏まえて、本題であるElasticsearchの運用について説明していきたいと思います。
これまでのLINEデリマのトピックを大きく分けると3つあります。1つめは、リリース日に某ビジネス番組でプレスリリースの様子が報道されて、そのときに対応した内容になります。2つめは、AdminページからElasticsearchを利用させて欲しいというような依頼があり、その対応を行った話になります。
そして3つめが、某バラエティ番組でサービスの紹介が行われることになり、そのためにElasticsearchのパフォーマンス・チューニングを行った話になります。
ではまず、プレスリリース時の対応についてです。サービスのリリース日である7月26日にプレスリリース配信とプレスイベントが行われて、そのプレスイベントの様子が報道されました。この放送の影響で用意していたサーバー数では耐えきれないリクエスト数があり、Elasticsearchのリソースが枯渇して、リクエストをリジェクトしてしまうようになってしまいました。
このときにElasticsearchが受けたリクエストは、1台あたり秒間約4,000リクエストになります。
急遽2台のサーバーをクラスタに追加したんですが、弊社ではverdaと呼ばれるOpenStack製のプライベートクラウドを利用しているので、即座に用意してデータを2台増やすことができました。
この結果、クラスタは次のような構成になりました。
リリース時のクラスタにデータノードが2台追加される構成になっています。この状態でもマスターノードは1台のみで稼働している状態です。この構成で当日は事なきを得ました。
翌日からクラスタの改善に着手しました。まず、先ほどもみてわかるように一番の問題がマスターノードが1台しか存在していないというところで、もしそのマスターノード1台がダウンしてしまった場合に、クラスタとしての構成が失われてしまって、インデックスの作成などが行えなくなってしまうので、早急にこれらの改善を行わなければならないと判断しました。
また、増設にあたってはマスターノードをクラスタの管理のみに集中させたかったので、マスターノードとしてのみ稼働するノードを増やすことにしました。
Elasticsearchのクライアントの設定にもよるんですが、検索フロー上、マスターノードに検索リクエストを行った場合はデータノードから検索結果をフェッチするように動作すると思うので、クライアントであるAPIサーバーがデータのほうにのみリクエストを行うようにアプリケーションの改修も行いました(注:この動作についてはライブラリのオプションを有効化することで回避することも可能)。
検証を行った結果、Elasticsearchはマスターノードのみで稼働させた場合にほとんど負荷がかからない状態となっているので、先ほど説明した社内のプライベートクラウド上でVMを3台用意しました。
また、先ほどのシャードの数の話がありましたが、検証を行った結果、1ノードが2シャードを持つ状態がもっともパフォーマンスが上がったので、プライマリーシャードをデータノード数、レプリカシャード数を1つで、1ノードが2つのシャードを持つ状態にチューニングを行いました。
この結果、クラスタは次のような構成になりました。
こちらが改善後のクラスタになります。先ほどもお伝えしたとおり、3台のVMマシンがマスターノードとして稼働して、データノード5台を管理するかたちになっています。
また、クライアントであるAPIサーバーは5台のデータノードにのみリクエストを行うようになっています。実際の作業内容に関しては、作業自体はマスターノードを事前にセットアップしておいて、当日マスターノードを起動してクラスタに追加、そして既存のマスターノードをデータノードに変更する、というようなものです。全体の作業時間は20分程度で完了しました。
最初にお伝えしているとおり、数分ごとにバッチがElasticsearchに対してインデクシングを行っているんですが、データ量も少なかったので、今回はバッチも停めずに稼働させた状態で作業を行いました。
ですが、作業が増える反面、バッチを停めてリバランスやアロケーションといったシャードの移動を停めた状態に設定してシャードの整合性を保った状態で作業を行ったほうが、高速にリカバリーされかつ安全かと思います。
今回の作業ではとくに問題にはならなかったんですが、通常時に5Mbpsほどのトラフィックがシャードのフィードなどによって20Mbpsになっていたため、もし通信量が多いような環境だと問題になるかと思います。
では次に2つめのトピックとして、サービスで利用しているデータノードに影響を与えないようにAdminページからElasticsearchを利用したいというような要望が挙がりました。
この要望に対応するために新たにクラスタを構築するのは管理コストなどの問題があると思ったので、今回は既存のクラスタをサービスとAdminの2つの区画に分けるということで対応を行うことにしました。以降、この区画のことはゾーンというように呼称します。
今回追加したのは先ほども申しあげたとおりサービスとAdminの2つのゾーンになります。設定自体はelasticsearch.ymlセットファイルに、こちらに記載されている設定を追加してサーバーをリスタートさせるというようなことになります。
こちらの設定を行ったあとのクラスタの構成が次の図になっています。
バッチのゾーンでも、最低限冗長化を構成するために2台の物理サーバーで基本のクラスタに追加を行っております。こちらの構成でAPIサーバーからはサービス用のゾーンに対して、AdminサーバーからはAdmin用のゾーンのサーバーに対してリクエストを行うような構成になっています。
ではゾーンを追加したことによりどのような状態になるのかを説明したいと思います。クラスタは各ゾーンには分かれてはいるものの、インデックスは共通していて、管理は同じマスターノードが行っています。
設定を追加したことによって、Elasticsearchはゾーンごとにインデックスが完全な状態になろうとするため、事前にレプリカ数を増やしておいてからリバランシングを実施させる必要があります。
ここでいう完全な状態のインデックスとは、例えばプライマリーシャードが5個ある状態だった場合に、新たなゾーンでもこの5個のシャードを配置するようにElasticsearchがシャードの移動を行うというようなものになります。
リバランスが完了したあと各ゾーンのサーバーがなんらかの原因によりダウンした場合は、同じゾーンでシャードの移動が発生します。
今回はデータノードに影響を与えずに、Admin用のElasticsearchを追加したいというような依頼だったのですが、ゾーンを分けることによって検索フローが同じゾーン内に閉じるので、この要件を満たすこともできました。
先ほどの図であったとおり、APIサーバーが投げたリクエストはサービス用のゾーン内にのみ検索が行われ、Adminで投げた、Adminサーバーが投げたリクエストはAdminのゾーン内のみで検索が行われるということだとなります。
これで、今回の、サービスに影響を与えないElasticsearchクラスタを構築することができました。
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05