LinkedInは「最大毎秒480万リクエスト」をどうさばいているのか:ストレージの高負荷に対処しながらサービスコストを10%削減
ピーク時には毎秒480万人以上の会員プロフィールを提供するLinkedIn。年々負荷が高まるストレージインフラを改善するため「Couchbase」を採用した。採用にいたったいきさつや導入後の問題にどう対処したか、公式エンジニアリングブログで解説した。
ピーク時には毎秒480万人以上の会員プロフィールを提供するLinkedIn。ストレージインフラへのリクエスト数は年々増えており、コアコンポーネントの高負荷により、スケーリングの懸念に対処できないほど事態は深刻になっていた。
そこでLinkedInは、読み取りスケーリング用の集中型ストレージ層キャッシュとしてNoSQLデータベースである「Couchbase」を導入した。99%以上のキャッシュヒット率を達成し、テールレイテンシは60%以上削減。サービスコストは年間で10%の削減に成功したという。
LinkedInは公式エンジニアリングブログで、Couchbaseの採用に至ったいきさつや導入後の問題にどう対処したか解説した。
LinkedInのストレージインフラの歴史
LinkedInのプロフィールバックエンドには、アプリケーションとデータベース間の読み取りキャッシュとしてインメモリデータストアであるmemcachedを利用した集中型キャッシュを採用していた。しかし、キャッシュの拡張やノードの交換、キャッシュのウォームアップの問題などでパフォーマンスが低下しており、memcachedのメンテナンスも困難だった。
2014年、LinkedInはOracleから独自に開発したNoSQLデータベースである「Espresso」に移行した。Espressoに内蔵されたスケーラビリティとレイテンシの特性により、リードキャッシュは不要になった。しかし、Espressoとともにバックエンドアプリケーションのクラスタサイズを拡張することで、Espressoの共有コンポーネントの上限にぶつかり、上限を上げるための大規模なエンジニアリング投資が必要にもなった。
スケールアップを目的にCouchbaseを採用
会員プロフィールのリクエストは、読み込みが99%以上、書き込みが1%未満という特徴を持つ。そのため、プロフィール情報を保存しているEspressoデータストアを拡張する方法を検討する際に、キャッシングが選択肢の一つとして検討された。
Espressoクラスタはハードウェアによる容量拡張の限界に達しており、これ以上は大規模な再設計が必要だった。以前よりCouchbaseはLinkedInで広く使用されており、Couchbaseのキャッシュはストレージレイヤーに置くことができるため、アプリケーション所有者はキャッシュの内部を扱う必要がないという利点もあった。
なお、スケールアップの目的でキャッシュを使用するため、信頼できる情報源(SOT:Source of Truth)から完全に独立して動作する必要もあった。
キャッシュ設計の戦略
Couchbaseで障害が発生したとしても、SOTにフォールバックできないため、Couchbaseの耐障害性は非常に重要だ。キャッシュの障害が新たな障害につながってしまうことを防ぐため、以下の原則に基づき、ガードレールを実装した。
- Couchbaseの耐障害性を保証する
- 常時キャッシュデータが利用できる状態にする
- SOTとキャッシュの間における厳密に定義されたSLO(サービスレベル目標)
Espressoルーター
ルーターがアクセスする全てのCouchbaseバケットの健全性を追跡するために、全てのルーターでCouchbaseヘルスモニターを維持する。ヘルスモニターは、所定のしきい値に対するリクエスト例外率に基づいてバケットの健全性を評価する。バケットが健全でない場合、ルーターはバケットへの新しいリクエストの転送を停止する。これによりクライアントのタイムアウトやルーターの障害を防ぐ。
Couchbaseリーダーのレプリカ障害
3つのレプリカ(リーダーのレプリカと2つのフォロワーのレプリカ)をプロフィールデータ用に持つことを選択し、リーダーとフォロワーのAPIを実装する。そして、全てのリクエストはリーダーのレプリカで処理される。リーダーのレプリカが失敗した場合、ルーターはフォロワーのレプリカからデータを取得する。
Couchbaseリクエストの再試行
Couchbaseの障害は、さまざまな理由で引き起こされる可能性はあるが、Couchbaseの例外を以下の3つのカテゴリーに分類してリクエストを再試行するようにした。
- Espressoルーターの問題
- ネットワークの問題
- Couchbaseサーバ側の問題
またキャッシュされたデータをいつでもどこでも利用できるようにするため、LinkedInはプロフィールデータセット全体を全てのデータセンターにキャッシュすることにした。だが、これはデータの一貫性が永続的に失われるリスクも伴う。そこで、キャッシュデータにはTTLを設定し、期限切れのレコードがCouchbaseから自動的に削除されるようにした。
コストの削減
LinkedInによると、これらの取り組みによりEspressoのストレージノード数を90%削減できた。だが、データの抽出や変換などのパフォーマンスを強化する必要があり、その分のコストは一部増加したという。結果として、一連の取り組みは全体の効率化につながり、LinkedInの会員プロフィールリクエストに対応するコストは年間約10%削減できたとしている。
LinkedInは、EspressoとCouchbaseの活用により、会員数の増加に伴うパフォーマンスの低下やユーザーへの影響を防ぎながらサービス提供コストを削減する目標を達成できた。一方、この一連の取り組みを実現するのに1.5年以上を費やしたとしている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- PayPal、可用性の高いキーバリューストア「JunoDB」をオープンソースで公開
PayPalは、可用性の高いキーバリューストア「JunoDB」を公開した。JunoDBの最優先事項はセキュリティで、TLSのサポートとペイロードの暗号化により、ワイヤ上と静止状態の両方でデータを保護する。 - 「スケールアウトできる『PostgreSQL』」――Yugabyte Japanに聞く「分散SQLDB」のメリット
なぜ「分散SQLDB」が注目を集めているのか。日本国内における分散SQLDBの普及に注力しているYugabyte Japanに「分散SQLDB」とその利点を伺いました。記事後半では2022年3月に開催されたアジア圏向けイベント「Distributed SQL Summit Asia」の内容を紹介します。 - ソフトウェア開発で気を付けたい脆弱性トップ25 3位は「SQLインジェクション」 2位は「XSS」 1位は?
MITREは、ソフトウェアにおいて危険な脆弱性タイプの1位〜25位をまとめた「CWE Top 25」を発表した。