Amazon Aurora を使用してエンドユーザーの待ち時間を 3 倍に改善する方法
Amazon Aurora を使用してエンドユーザーの待ち時間を 3 倍に改善する方法:
我々のビジネスはシンプルです。日常の消費者がショッピングレシートの写真を撮影してクラウドにアップロードが可能なモバイルアプリケーションのポートフォリオを持っています。我々はこのデータを分析し、ブランド、小売業者、代理店、消費者パッケージ商品 (CPG) 企業の買い物客に深い識見を提供します。大規模なデータ収集に対するこの消費者中心のアプローチは、ブランドが最終的に非常に多くの問いの背後にある「なぜ」に答えることを可能にします。「なぜ、私のカテゴリーで売上高が 5％ 減少したのでしょうか ? 」「このカテゴリーのどのような消費者シフトが私のブランドに売上に貢献しているのでしょうか ? 」「消費者のどのセグメントがオンラインに移行しているのでしょうか ? 」 米国では 500 回の購入で 1 回のキャプチャを行い、1 日に 300,000 枚のレシート画像をストリームします。
AWS でインフラストラクチャとアプリケーション全体を強化するために、Amazon EC2 、Amazon RDS 、Amazon S3 、Amazon VPC 、および Route 53 を大量に使用しています。2011 年にはカリフォルニア北部の single VPC 1 台を使い始めましたが、2016 年にはデータパイプラインと顧客の需要に追いつくため、AWS のフットプリントを拡大しています。我々は Amazon Aurora と AWS Lambda に興味を抱いていましたが、これらは我々の地域では利用できませんでした。そのため、ステップ 1 は、フットプリントを Oregon の新しい場所へ移行していました。
2016 年 11 月と 12 月には、複数のデータベースを含む 100 以上のサーバーを移行しました。AWS での成長の第2段階が始まりました。
InfoScout のプライマリトランザクションデータベースは、Amazon RDS for MySQL インスタンスで構成されていました。コンシューマーデータベースバックエンドとして機能を果たし、モバイルユーザーデータ、サーベイデータ、およびレシートデータをすべて格納しました。この構成には、高可用性と ETL の両方に使用されるシングルマスターデータベースと 2 つのリードレプリカが含まれていました。データベースが成長するにつれて、インスタンスを垂直方向に拡大していき、MySQL 用の Amazon RDS によってサポートされる最大のインスタンスサイズに最終的にアップグレードしました。このアプローチは当初から行われていましたが、データベースのサイズが数テラバイトに拡大したため、トラフィックの多い期間に 2 つの大きな問題が出現しました。
まず、クエリ実行時間の全体的なパフォーマンスに負担がかかっていました。負荷がピーク時には、同時に発生するリクエストが多すぎるため、Amazon RDS インスタンスのキューの深さが大幅にバックアップされます。キューの深さは 50 、100 、または 125 で、I/O レベルの操作のバックログを示します。これにより、読み取りが遅くなり、ページがタイムアウトになり、ジョブが失敗しました。次に、ストレージが問題となっていました。その時点での Amazon RDS for MySQL の最大記憶容量は 6 テラバイトでした (現在は最大 16 テラバイトをサポートしています)。我々のデータベースはすでに 5 テラバイトでした。
これらのパフォーマンスとストレージの問題があったため、MySQL の準備をするために貴重な時間とリソースを費やしていました。交通量の多い時期に問題が発生した場合は、必須ではないその他のサービスを停止する必要があります。これにより、データベースの負荷が軽減されます。一定の Amazon CloudWatch アラートが他の責任に影響を与えました。
データベースクラスタをシャーディングしたり、マイクロサービスにリッピングしたり、古いデータをアーカイブしたり、または Amazon EC2 上の MySQL に移行したりするなど、問題を管理するためにさまざまな可能性を評価しました。しかしこれらの選択肢は、我々の成長率を考慮すると、あまりにも複雑で持続不可能なように思われました。アカウントマネージャーと AWS ソリューションアーキテクトとのわずかな会話の後、我々はプライマリデータベースの新しい宛先として MySQL 互換性を備えた Aurora を調べ始めました。
最初は Aurora を心配していました。それは比較的新しく、その独自の性質は他のアーキテクチャーコンポーネントと一致せず、また MySQL データベースで実際にプラグアンドプレイできるのか疑問でした。しかし、スケーラビリティと機能セットに我々は魅了されました。低コスト、高速なパフォーマンス、短期間のレプリケーション遅延、そして最大 64 テラバイトの記憶域により、近い将来いつでもデータベースをシャードする必要はありませんでした。
モバイルバックエンドのおよそ 250 テーブルのうち、その大半は MySQL InnoDB ストレージエンジンを使用していました。古い MyISAM ストレージエンジンには 12 個ほどありました (レガシー FULLTEXT 検索クエリをサポートするため)。Aurora は InnoDB とは互換性がありますが、MyISAM とは対応していません。つまり、直ちに MyISAM テーブルを InnoDB へ移行する必要があることを意味していました。この移行が完了した後、ステージング環境全体を Aurora に移行し、Amazon RDS for MySQL ステージング環境を廃止しました。
以降 2〜3 週間、Aurora のステージング環境のパフォーマンスのテスト、チューニング、およびモニターを行い、状況は良好に見えました。内部テスト用のステージング環境では、明らかに実稼働環境が得られるトラフィックは得られません。しかし、論理的な SQL の観点からは、すべてがエンドツーエンドで動作していました。Aurora クラスタへのコールは期待通りに機能し、データはスムーズに流れていました。我々は今、MySQL との互換性により Aurora に対する高い信頼を得ました。
2017年夏にステージング環境にゴーサインが与えられた後、移行のチェックリストを作成しました。それは次の通りでした。
我々は CloudWatch の大ファンであり、Celery workers の大規模な非同期ファームのパフォーマンスをモニタリングするために定義された約 20 のメトリックを持っています。Aurora に移行した後、レシートエンジンステートマシンの重要なステップの 10 倍の短縮時間に気が付きました。このタスクは、画像の複製と最新のレシート提出の検証を担いっています。次のグラフは、レシートパイプラインで重要な非同期ジョブの実行時間を示しています。実行時間が 4 秒から 400 ミリ秒へと 10 倍短縮されていることがわかります。
AWS のモニタリングツールに加えて、深刻なパフォーマンスをモニタリングするために New Relic のようなプロダクショングレードのサービスを使用します。我々はそれらのレポートを取り出し、ゲートからの応答時間が 3 倍改善されたことを確認しました ! MySQL 用の Amazon RDS を使用していたとき、モバイルクライアントがバックエンドに行った標準的なネットワークコールには、600 ミリ秒かかりました。そのほとんどは MySQL クエリ内で費やされました。Aurora に導入した後、この待ち時間は 200 ミリ秒以下に短縮されました。これらの初期測定基準を確認した後、インフラストラクチャチームは、6 テラバイトのトランザクションデータクラスタの新しいホームを発見したと確信していました。次のグラフは、移行前後の待ち時間を示しています。パフォーマンスがすぐに向上することがわかります。
Aurora は最も賢明な選択肢のように見えましたが、移行の決定は他と無関係ではありませんでした。Aurora の移行が最も理にかなっているか否かについて、チームとの会話をまとめました。MySQL は安定かつ堅固で、数十年も前から存在しています。我々はまだこの技術を信じています。しかし、1 分間に 20,000 件を超えるクエリを扱う大規模なデータベースがあり、MySQL だけではストレスを吸収することができませんでした。
何らかの理由で移行を検討している場合、最もホットなテクノロジーを追いかけるということだけではありません。すべてのオプションを評価し、チームとして検討してください。既存の運用環境をテストし、慎重に問題を文書化してください。また、新しいステージング環境を要件のチェックリストと照らし合わせて各項目をテストします。このアプローチは我々にとって有益でした。Aurora に移行してからすでに成長しており、新しいデータベースは着実に高性能で稼動しています。新しいデータベースエンジンとして Aurora に満足しており、Aurora を事業に合わせて拡張できると確信しています。
規模について言えば、今後数週間で受付番号 5億 を祝うことを見込んでいます ! すべてのことを可能にするために、AWS のチームへ称賛を与えました。
InfoScout アプリケーションアーキテクチャ
Dana Ford 氏は、InfoScout のシニアエンジニアリングディレクターであり、消費者向けのモバイルアプリとプラットフォームチームのために製品とエンジニアリングをリードしています。同氏は過去 4 年間我が社に勤務し、拡大するお客様のニーズに対応するために AWS の大きな展開を拡大を支援してきました。
Doug Flora 氏は、アマゾン ウェブ サービスのAmazon Relational Database Service (RDS) のシニアプロダクトマーケティングマネージャです。
AWS で誕生
2011年の創業以来、我々の旅に加わっている InfoScout は AWS で誕生しました。友人や家族からアップロードされたレシートを収集する 1 つの Amazon EC2 インスタンス とともにすべてが始まりました。それから7年後、モバイルアプリケーション、データパイプライン、マシンラーニングモデル”→”機械学習モデル、SaaS 分析プラットフォームをサポートするため、現在では 150 以上の AWS インスタンスを管理しています。この記事では、増加するインフラストラクチャとデータベース移行での課題を詳細に分析しています。我々のビジネスはシンプルです。日常の消費者がショッピングレシートの写真を撮影してクラウドにアップロードが可能なモバイルアプリケーションのポートフォリオを持っています。我々はこのデータを分析し、ブランド、小売業者、代理店、消費者パッケージ商品 (CPG) 企業の買い物客に深い識見を提供します。大規模なデータ収集に対するこの消費者中心のアプローチは、ブランドが最終的に非常に多くの問いの背後にある「なぜ」に答えることを可能にします。「なぜ、私のカテゴリーで売上高が 5％ 減少したのでしょうか ? 」「このカテゴリーのどのような消費者シフトが私のブランドに売上に貢献しているのでしょうか ? 」「消費者のどのセグメントがオンラインに移行しているのでしょうか ? 」 米国では 500 回の購入で 1 回のキャプチャを行い、1 日に 300,000 枚のレシート画像をストリームします。
AWS でインフラストラクチャとアプリケーション全体を強化するために、Amazon EC2 、Amazon RDS 、Amazon S3 、Amazon VPC 、および Route 53 を大量に使用しています。2011 年にはカリフォルニア北部の single VPC 1 台を使い始めましたが、2016 年にはデータパイプラインと顧客の需要に追いつくため、AWS のフットプリントを拡大しています。我々は Amazon Aurora と AWS Lambda に興味を抱いていましたが、これらは我々の地域では利用できませんでした。そのため、ステップ 1 は、フットプリントを Oregon の新しい場所へ移行していました。
2016 年 11 月と 12 月には、複数のデータベースを含む 100 以上のサーバーを移行しました。AWS での成長の第2段階が始まりました。
産みの苦しみ
多くのスタートアップ企業と同様に、スケーリングの課題も経験しました。最優先事項は、データベースのスループットとパフォーマンスを向上させることでした。オレゴン州へ移る以前から、ビジネスが成長するにつれてデータベースパフォーマンスの問題を経験し始めました。InfoScout のプライマリトランザクションデータベースは、Amazon RDS for MySQL インスタンスで構成されていました。コンシューマーデータベースバックエンドとして機能を果たし、モバイルユーザーデータ、サーベイデータ、およびレシートデータをすべて格納しました。この構成には、高可用性と ETL の両方に使用されるシングルマスターデータベースと 2 つのリードレプリカが含まれていました。データベースが成長するにつれて、インスタンスを垂直方向に拡大していき、MySQL 用の Amazon RDS によってサポートされる最大のインスタンスサイズに最終的にアップグレードしました。このアプローチは当初から行われていましたが、データベースのサイズが数テラバイトに拡大したため、トラフィックの多い期間に 2 つの大きな問題が出現しました。
まず、クエリ実行時間の全体的なパフォーマンスに負担がかかっていました。負荷がピーク時には、同時に発生するリクエストが多すぎるため、Amazon RDS インスタンスのキューの深さが大幅にバックアップされます。キューの深さは 50 、100 、または 125 で、I/O レベルの操作のバックログを示します。これにより、読み取りが遅くなり、ページがタイムアウトになり、ジョブが失敗しました。次に、ストレージが問題となっていました。その時点での Amazon RDS for MySQL の最大記憶容量は 6 テラバイトでした (現在は最大 16 テラバイトをサポートしています)。我々のデータベースはすでに 5 テラバイトでした。
これらのパフォーマンスとストレージの問題があったため、MySQL の準備をするために貴重な時間とリソースを費やしていました。交通量の多い時期に問題が発生した場合は、必須ではないその他のサービスを停止する必要があります。これにより、データベースの負荷が軽減されます。一定の Amazon CloudWatch アラートが他の責任に影響を与えました。
データベースクラスタをシャーディングしたり、マイクロサービスにリッピングしたり、古いデータをアーカイブしたり、または Amazon EC2 上の MySQL に移行したりするなど、問題を管理するためにさまざまな可能性を評価しました。しかしこれらの選択肢は、我々の成長率を考慮すると、あまりにも複雑で持続不可能なように思われました。アカウントマネージャーと AWS ソリューションアーキテクトとのわずかな会話の後、我々はプライマリデータベースの新しい宛先として MySQL 互換性を備えた Aurora を調べ始めました。
最初は Aurora を心配していました。それは比較的新しく、その独自の性質は他のアーキテクチャーコンポーネントと一致せず、また MySQL データベースで実際にプラグアンドプレイできるのか疑問でした。しかし、スケーラビリティと機能セットに我々は魅了されました。低コスト、高速なパフォーマンス、短期間のレプリケーション遅延、そして最大 64 テラバイトの記憶域により、近い将来いつでもデータベースをシャードする必要はありませんでした。
Aurora への移行
データベース製作用の Aurora に移行する前に、いくつか追加の互換性チェックを解決し、ステージング環境をテストしてチューニングする必要がありました。モバイルバックエンドのおよそ 250 テーブルのうち、その大半は MySQL InnoDB ストレージエンジンを使用していました。古い MyISAM ストレージエンジンには 12 個ほどありました (レガシー FULLTEXT 検索クエリをサポートするため)。Aurora は InnoDB とは互換性がありますが、MyISAM とは対応していません。つまり、直ちに MyISAM テーブルを InnoDB へ移行する必要があることを意味していました。この移行が完了した後、ステージング環境全体を Aurora に移行し、Amazon RDS for MySQL ステージング環境を廃止しました。
以降 2〜3 週間、Aurora のステージング環境のパフォーマンスのテスト、チューニング、およびモニターを行い、状況は良好に見えました。内部テスト用のステージング環境では、明らかに実稼働環境が得られるトラフィックは得られません。しかし、論理的な SQL の観点からは、すべてがエンドツーエンドで動作していました。Aurora クラスタへのコールは期待通りに機能し、データはスムーズに流れていました。我々は今、MySQL との互換性により Aurora に対する高い信頼を得ました。
2017年夏にステージング環境にゴーサインが与えられた後、移行のチェックリストを作成しました。それは次の通りでした。
- MySQL Master DB 用の Amazon RDS から Aurora 読込用レプリカを 2 つスピンアップする
- Aurora のレプリカが追いつくのを待ちつと、すぐに起きる
- すべてのコンシューマトラフィックと非同期 Python Celery キューをオフにする
- MySQL マスターパスワードを変更し、不正なプロセスが MySQL DB に書き込みを行っていないことを確認する
- Aurora テーブルを検証し、MySQL マスターに書き込みはない
- 1 つの Aurora DB を新しいマスタ DB にプロモートする
- ルート Route 53 DNS を更新して、DB エンドポイントを新しい Aurora DB にポイントするために記録する
- ブートコンシューマアプリケーション、Celery キュー、およびその他のサービスを起動する
結果
以下は、カットオーバー前と実行後の実行時間、そして待ち時間を強調するグラフです。すぐにパフォーマンスが向上することがわかります。我々は CloudWatch の大ファンであり、Celery workers の大規模な非同期ファームのパフォーマンスをモニタリングするために定義された約 20 のメトリックを持っています。Aurora に移行した後、レシートエンジンステートマシンの重要なステップの 10 倍の短縮時間に気が付きました。このタスクは、画像の複製と最新のレシート提出の検証を担いっています。次のグラフは、レシートパイプラインで重要な非同期ジョブの実行時間を示しています。実行時間が 4 秒から 400 ミリ秒へと 10 倍短縮されていることがわかります。
AWS のモニタリングツールに加えて、深刻なパフォーマンスをモニタリングするために New Relic のようなプロダクショングレードのサービスを使用します。我々はそれらのレポートを取り出し、ゲートからの応答時間が 3 倍改善されたことを確認しました ! MySQL 用の Amazon RDS を使用していたとき、モバイルクライアントがバックエンドに行った標準的なネットワークコールには、600 ミリ秒かかりました。そのほとんどは MySQL クエリ内で費やされました。Aurora に導入した後、この待ち時間は 200 ミリ秒以下に短縮されました。これらの初期測定基準を確認した後、インフラストラクチャチームは、6 テラバイトのトランザクションデータクラスタの新しいホームを発見したと確信していました。次のグラフは、移行前後の待ち時間を示しています。パフォーマンスがすぐに向上することがわかります。
成長するデータベース
データベース環境の移行または再構築のオプションを評価する場合、いくつかの要素を考慮しました。最終的には、運用オーバーヘッドとインフラストラクチャ管理が関係しているため、シャーディングのルートや独自のクラスターを構築することは望ましいことではありませんでした。データベースの管理と運用に費やされた時間が、機能の開発、エンジニアリングに取り組むこと、そして企業の成長を支援できないことを懸念していました。このことは、最終的に我々のビジネススピードに悪影響を及ぼします。Aurora は最も賢明な選択肢のように見えましたが、移行の決定は他と無関係ではありませんでした。Aurora の移行が最も理にかなっているか否かについて、チームとの会話をまとめました。MySQL は安定かつ堅固で、数十年も前から存在しています。我々はまだこの技術を信じています。しかし、1 分間に 20,000 件を超えるクエリを扱う大規模なデータベースがあり、MySQL だけではストレスを吸収することができませんでした。
何らかの理由で移行を検討している場合、最もホットなテクノロジーを追いかけるということだけではありません。すべてのオプションを評価し、チームとして検討してください。既存の運用環境をテストし、慎重に問題を文書化してください。また、新しいステージング環境を要件のチェックリストと照らし合わせて各項目をテストします。このアプローチは我々にとって有益でした。Aurora に移行してからすでに成長しており、新しいデータベースは着実に高性能で稼動しています。新しいデータベースエンジンとして Aurora に満足しており、Aurora を事業に合わせて拡張できると確信しています。
規模について言えば、今後数週間で受付番号 5億 を祝うことを見込んでいます ! すべてのことを可能にするために、AWS のチームへ称賛を与えました。
InfoScout アプリケーションアーキテクチャ
今回のブログ投稿者について
コメント
コメントを投稿