タップルは、好きなことから恋の相手を見つけることができるマッチングアプリです。株式会社サイバーエージェントのグループ会社である株式会社タップルが運営する、日本国内最大規模のマッチングアプリになります。
タップルは主に、恋活中の若い人たちが使っています。アンケート調査でも利用満足度が最も高く、累計会員数は1,900万人を超え、累計マッチング成立数は5億組を超えています。さらに、毎日40万組以上のマッチングが成立し、毎月10,000人のカップルが誕生しています。

Amazon OpenSearch Serviceは、インタラクティブなログ分析、リアルタイムのアプリケーション監視、ウェブサイト検索などを簡単に実行できるサービスです。OpenSearchは、Elasticsearchから派生したオープンソースの分散型検索および分析ソフトウェアです。Amazon OpenSearch Serviceは、OpenSearchの最新バージョンを提供し、Elasticsearch（バージョン7.10まで）もサポートしているほか、OpenSearch DashboardsとKibanaを利用したビジュアライズ機能も提供しています。Amazon OpenSearch Serviceには現在、何万ものアクティブなお客様がいて、数十万のクラスターが管理されており、毎月何兆ものリクエストを処理しています。

タップルは、監視業務の一部に独自のアプリケーションログ基盤を使用してきました。この基盤には、タップルユーザーがマッチングアプリを操作するたびに記録されるアプリケーションログが保存されるため、タップルのエンジニアはサービスで発生する問題の修正に役立つログにすぐにアクセスすることができます。しかし、マッチングアプリが人気を獲得したことで、このアプリケーションログ基盤にスケーリング上の課題が発生しました。既存のソリューションのままでは、ログが増えるにつれて、インフラが肥大化して管理コストが増加するという課題が生まれたのです。そこで、この課題を解消するために、タップルはAmazon OpenSearch IngestionとOR1インスタンスを採用することに決めました。
この投稿では、タップルがOpenSearchソリューションに関連する安定性の向上、肥大化の解消、コストの削減に取り組み、マッチングアプリの顧客体験を向上させるために行った取り組みを振り返ります。

既存のアプリケーションログ基盤の課題

タップルは、マッチングアプリの初期デプロイ時からAmazon OpenSearch Serviceを利用しています。アプリケーションログ基盤は、直近1か月のデータを保持するAmazon OpenSearch Serviceドメインと、データを長期間アーカイブするAmazon S3とAmazon Athenaで構成されています。既存のソリューションでは、コンテナホストからそれらにFluent Bitエージェントでログを直接書き込むよう構成されていました。

以前のアーキテクチャ

タップルが人気を得るとともにユーザーベースが拡大しました。そして、その成長を支えるべく、スケーラビリティ向上のためにモノリシックアーキテクチャからマイクロサービスアーキテクチャへ移行しました。ユーザーの増加と、サービスの成長に応じて既存ソリューションの構成を見直したことによりログを記録する振る舞いの数が増加したことで、ログの量も増加しました。タップルは、ロギング処理の影響をOpenSearchクラスターのスケーリングへの影響から切り離して、成長に対応する方法を必要としていました。
このアプリケーションログ基盤は、タップルユーザーがアプリを操作するたびに、マイクロサービスからアプリケーションログを継続的に直接受信していました。そして、その主な用途は、タップルのエンジニアがサービスに問題が発生した場合にOpenSearch Dashboardsからログを照会して調査することです。全体として、Amazon OpenSearch Serviceドメインの負荷は、ユーザーの行動による継続的なインデックスと、エンジニアの操作による時折の検索クエリであるため、書き込みが多いという特徴があります。目標は、書き込みの多い特性を考慮して、インデックス・検索（書き込み・読み取り）の性能を維持しながら、コストを削減し、安定性を向上させることでした。

通常、このような問題が発生した場合は、トラフィックの急増を防ぎ、Amazon OpenSearch Serviceに送信されるペイロードのサイズを管理するのに役立つバッファを導入します。
また、一般的に、ビジネスが成長して規模が拡大するにつれて、Fluent BitからAmazon OpenSearch Serviceに直接書き込むことが課題になります。アプリケーションのロギングをサポートするためにエージェントの数が増えるにつれて、複数のエージェントから発生する小さな取り込みペイロードの非効率性が、安定性のアンチパターンをもたらし、その結果、書き込まれるデータの量に対応できるようにOpenSearchクラスターを拡張する必要が発生します。
Fluent Bitエージェントはそれぞれ独立して動作します。たとえば、各エージェントが数十個程度のドキュメントのペイロードを送信し、他のエージェントも同様に送信した場合、それらの小さなペイロードがOpenSearchの取り込みキューをいっぱいにすることがあり得ます。このような懸念に対処するために、通常はOpenSearchクラスターをスケールアップまたはスケールアウトしますが、これが肥大化やコストの問題の一因となります。

さらなる成長と持続可能な事業を実現するために、タップルはサービスのバックエンドを構成するAWSリソースを見直しました。構成の見直しの過程で、アプリケーションログ基盤のAmazon OpenSearch Service部分に改善の余地があることがわかりました。
一方、Amazon S3とAmazon Athenaによるアーカイブに関して特に問題はなかったので、タップルはAmazon OpenSearch Serviceドメインの改善に注力しました。

ソリューションの概要

AWSとともに検討を進めたところ、タップルはAmazon OpenSearch Ingestionを利用してスパイクに対処し、より一貫性のあるペイロードサイズを作成して、クラスターの健全性を促進できることに気付きました。さらに、タップルの規模ではコストが懸念されることから、AWSはお客様に、比較的新しくリリースされたAmazon OpenSearch OR1インスタンスの使用を検討するよう提案しました。このインスタンスでは、アクティブに書き込まれていないインデックスにレプリカを作成する必要はありません。

OR1インスタンスは実際にはレプリカをAmazon S3に保存します。データを長期間保持し、コストを重視する多くのお客様にとって、OR1インスタンスは「ホットレプリカ」を必要としないため、データのコストを大幅に削減するのに役立ちます。耐久性のためにレプリカをAmazon S3に保存し、データノードに異常が生じた場合、そのレプリカはAmazon S3から引き戻され、障害が発生したデータノードが保持していたデータを再構成するために使用されます。これは結果的にコスト削減とデータの耐久性に寄与することを意味します。

Amazon OpenSearch Ingestion

まず初めに、タップルはAmazon OpenSearch Ingestionを導入しました。

Amazon OpenSearch Ingestonはフルマネージド型のサーバーレスデータコレクターで、リアルタイムのログなどをAmazon OpenSearch Serviceドメインに配信します。

タップルは、サービス開始当初はモノリシックアーキテクチャだったバックエンドを、サービスの成長に合わせてマイクロサービスアーキテクチャに変更しました。マイクロサービスへの移行の過程で、タップルを構成する各マイクロサービスは、Fluent Bitを使用してAmazon OpenSearch Serviceドメインに個別に直接書き込むようになりました。
今回の見直しによって、タップルは、これらの複数の直接インデックス経路を単一の集約経路に変更し、Amazon OpenSearch Ingestonを介してすべてのイベントストリームをドメインに書き込むことにしました。
さらに、Amazon OpenSearch Ingestionの採用に伴い、イベントストリームをAmazon OpenSearch ServiceドメインとAmazon S3バケットに直接二重に書き込むことをやめました。二重に書き込む代わりに、Amazon S3バケットをソースとしてAmazon OpenSearch Ingestionの前に置き、OpenSearch Ingestion Pipelineを1つにしました。
結果的に、インデックス経路をAmazon OpenSearch Ingestionに集約することで、Amazon OpenSearch Serviceドメインが受信するHTTPリクエストの数を30分の1に減らしました。

Amazon OpenSearch OR1インスタンス

今一度、本件のアプリケーションログ基盤の特徴を振り返ると、いくつかの明確な要件を確認できます。

1. Amazon OpenSearch Serviceドメインの負荷は、継続的に発生するアプリケーションログをインデックスし続ける必要があるため、書き込みによる影響が大きい。
2. クエリの実行頻度は非常に低いものの、ひとつひとつの検索クエリには高い応答速度が求められます。これは、サービスに問題が発生した場合に状況をすぐに確認する必要があるためです。
3. Amazon OpenSearch Serviceドメインに保持されるデータは、直近1か月のデータのみです。

タップルは、これらの特性がAmazon OpenSearch OR1インスタンスに適していると考え、新たなインスタンスとして採用しました。

OR1はAmazon OpenSearch Serviceのインスタンスで、大量のデータを費用対効果の高い方法で保存できます。OR1インスタンスのあるドメインは、Amazon EBS gp3またはio1ボリュームをプライマリストレージとして使用し、データはOpenSearchセグメントレプリケーションを使用してAmazon S3に同期的にコピーされます。このストレージ構造により、耐久性の高いインデックス（書き込み）スループットが可能になります。OR1インスタンスは、障害発生時の自動データ復旧もサポートしています。OR1の仕組みの詳細な説明については、こちらのAWS Big Data Blogの記事を参照してください。他にも、AWSは、こちらのAWS Big Data Blogの記事でor1.largeとr6g.largeを比較したパフォーマンスベンチマークの結果も公開しています。一般的な比較として参考にしてください。

上述の要件とAmazon OpenSearch Ingestionの導入による効果を考慮して、データノード用のAmazon OpenSearch Serviceドメインのインスタンスタイプとサイズは、以前はr6g.largeを使用していたところを、or1.2xlargeとしました。
さらに、OR1の採用に伴い、OpenSearchのシャードレプリカ設定も見直し、シャードサイズを最適化し、シャード数を減らしました（3分の1に削減）。この変更は、ストレージ構造と自動データ復旧によるOR1の耐久性と障害耐性を頼りにしています。インスタンスタイプ、インスタンスサイズ、シャード設定を変更することで、以前と同じインデックス・検索性能を維持しながら、Amazon OpenSearch Serviceドメインをスリム化することに成功しました。これは、タップルのアプリケーションログ基盤の性能要件も満たしています。
Amazon OpenSearch Ingestionの導入による効果に加えて、Amazon OpenSearch Serviceドメインを構成するインスタンスをOR1に変更し、さらにシャードを最適化することで、インスタンス数は90%以上削減されました。

導入効果

ここまで述べてきたように、Amazon OpenSearch Serviceの設定を最適化した結果は一目瞭然です。
インデックス経路を Amazon OpenSearch Ingestionに集約することで、Amazon OpenSearch Serviceドメインが受信するHTTPリクエストの量を劇的に減らすことができました。具体的には、リクエストの数が以前のレベルの30分の1に減りました。さらに、OR1インスタンスを使用するようにドメインを構成するインスタンスタイプを変更し、シャード構成を最適化することで、必要なインスタンスの総数が90%以上削減されました。
全体として、Amazon OpenSearch Serviceドメインのランニングコストを約45%削減しました。結果的に、タップルのアプリケーションログ基盤の性能要件を満たすのに十分コンパクトで費用対効果の高いAmazon OpenSearch Serviceドメインを獲得したのです。

株式会社タップル SRE 赤野 裕喜 氏
「Amazon OpenSearch Serviceクラスターの肥大化と管理コストの増大が課題でしたが、コスト削減と安定性向上を実現できました。」

最後に

読者の皆様の多くは、タップルが達成したように、安定性を損なうことなくコストを最適化することに深い関心を持っていると思います。IngestionやOR1インスタンスなどのAmazon OpenSearch Serviceの機能は、これらの目標を達成するのに役立ちます。
このような機能をどのように活用できるかについて詳しくは、AWSのドキュメントをご覧ください。また、必要に応じて、AWSアカウントチームに連絡して、Amazon OpenSearch Serviceの機能を活用して最適化するための具体的なサポートを受けてください。

最後に、この最適化に関わったすべての方々に感謝の意を表したいと思います。ありがとうございます。

このブログの著者

半場 光晴（Mitusharu Hamba）
アマゾンウェブサービスジャパン合同会社
ソリューションアーキテクト