何百万人ものユーザーのためのシステム設計 (パート2)
何百万人ものユーザーをサポートするシステムを設計することは小さな課題ではなく、継続的かつ継続的な改善が必要です。 何百万人ものユーザーのためのシステム設計（パート1）に続き、数百万人のユーザーに拡大するシステムを構築する方法を調べ続けます。
2022年04月01日
何百万人ものユーザーをサポートするシステムを設計することは小さな課題ではなく、継続的かつ継続的な改善が必要です。 何百万人ものユーザーのためのシステム設計（パート1）に続き、数百万人のユーザーに拡大するシステムを構築する方法を調べ続けます。
何百万人ものユーザーをサポートするシステムを設計することは小さな課題ではなく、継続的かつ継続的な改善が必要です。 何百万人ものユーザーのためのシステム設計（パート1）に続き、数百万人のユーザーに拡大するシステムを構築する方法を調べ続けます。
1. CDN
CDNは、静的コンテンツの配信に使用されるサーバーの地理的に分散したネットワークです。 静的コンテンツには、画像、ビデオ、CSSファイル、JSファイルなどがあります。
動的コンテンツキャッシングは新しい概念であり、この記事の範囲を超えています。 リクエストパス、クエリ文字列、Cookie、リクエストヘッダーに基づいてHTMLページをキャッシュできます。
CDNのワークフロー
・ユーザーが画像のURLを使用してimage.pngを取得した場合。 CDNによって提供されるURLのドメイン名。 最後の2つの画像URLは、AmazonサイトとAkamaiCDNでの画像URLの状態を示すために使用されます。
https://mysite.cloudfront.net/logo.jpg
https://mysite.akamai.com/image-manager/img/logo.jpg
・CDNサーバーのキャッシュにimage.pngがない場合、ネイティブWebサーバーまたはAmazonS3などのオンラインストレージからファイルを要求します。
・オリジンは、キャッシュされた画像の保存期間を説明するHTTPヘッダーTime-to-Liveを含むimage.pngをCDNサーバーに返します。
・CDNは画像をキャッシュしてユーザーAに返します。TTLが期限切れになるまで画像はキャッシュに残ります。
・ユーザーBが同じ写真にリクエストを送信します。
・TTLが満了していない場合、画像はキャッシュから返されます。
2. Stateless web tier
web tierをスケールアウトするには、Web層の状態を変換する必要があります。 これは、SQLやNoSQLなどの長期的なメモリ内セッションデータにとっての課題です。 クラスタ内の各Webサーバーは、データベースの状態データにアクセスできます。 これはstateless web tierと呼ばれます。
3. Stateful architecture
ステートフルサーバーとステートレスサーバーのいくつかの違いは、ステートフルサーバーは、ある要求から次の要求までクライアントのデータ（状態）を記憶することです。 ステートレスサーバーはその状態を記憶する必要はありません。
ユーザーAのセッションデータとユーザーイメージもサーバー1に保存されます。ユーザーAを認証するには、HTTPリクエストをサーバー1に送信する必要があります。リクエストがサーバー2などの別のサーバーに送信されると、リクエストはエラーを受け取ります。Aのセッションはそうではないためです。同様に、ユーザーBを認証するためのHTTP要求は、サーバー2に送信され、ユーザーCはサーバー3に送信される必要があります。
4. Stateless architecture
ステートレスアーキテクチャでは、ユーザーからのHTTPリクエストは、共有ストレージから状態データをロードする任意のWebサーバーに送信できます。 状態データは、Webサーバーの外部にあるデータ共有に保存されます。 ステートレスシステムは、よりシンプルで、より強力で、より拡張性があります。
セッションデータをWeb層から移動し、永続ストレージに保存します。 データ共有者は、RDBMS、Redis、NoSQLなどです。NoSQLは拡張性のための最も簡単な選択です。 Auto-scalingとは、トラフィックに基づいてWebサーバーを自動的に追加または削除するプロセスを意味します。 状態データがWebサーバーからクリアされた後、自動スケーリングが機能します。
ウェブサイトを徐々に拡大し、多くの海外ユーザーを魅了します。 可用性を向上させ、すべての地域でより良いエクスペリエンスを提供するには、複数のデータセンターをサポートすることが不可欠です。
5. データセンター
次の図は、2つのデータセンターの例です。
通常の操作では、ユーザーは地理的にルーティングされ、英語でgeoDNSルーティングされます。geoDNSは、ドメイン名をユーザーの場所に基づいてIPアドレスに解決できるようにするDNSサービスです。データセンターがダウンした場合、すべてのトラフィックを稼働中のデータセンターに転送します。
マルチデータセンターを設置する際に取り組むべき技術的課題
・交通ナビゲーション
適切なデータセンターへのトラフィックを促進するには、効果的なツールが必要です。 GeoDNSを使用すると、ユーザーの場所に基づいてトラフィックを最寄りのデータセンターに転送できます。
・データ同期
異なるドメインのユーザーは、異なるローカルキャッシュまたはデータベースを使用できます。フェイルオーバーが発生した場合、トラフィックはデータが利用できないデータセンターに転送される可能性があります。一般的な戦略は、複数のデータセンター間でデータを複製することです。
・テストと展開
マルチデータセンターのセットアップでは、さまざまな場所でWebサイト/アプリをテストすることが重要です。自動展開ツールは、すべてのデータセンターでサービスの一貫性を維持するために重要です。
6. Message Queue
メッセージキューは、非同期通信をサポートする永続的なメモリ内コンポーネントです。 バッファとして機能し、リクエストを非同期で配信します。 メッセージキューの基本的なアーキテクチャは非常に単純です。 パブリッシャーまたはプロデューサーと呼ばれる入力サービスは、メッセージを作成し、メッセージキューに公開します。 サブスクライバーまたはコンシューマーと呼ばれる他のサービスまたはサーバーがキューに接続し、メッセージで定義されたアクションを実行します。
デカップリングにより、メッセージキューは、拡張性と信頼性の高いアプリケーションを構築するための優れたアーキテクチャになります。 メッセージキューを使用すると、パブリッシャーはキューにメッセージを作成して、現在存在しないサブスクライバーが後でメッセージを処理できるようにすることができます。 サブスクライバーは、パブリッシャーがいない場合でもメッセージを読むことができます。
以下の画像では、Webサーバーが画像処理をメッセージキューにアップロードしています。 画像処理ワーカーは、メッセージキューから作業を受け取り、画像のカスタマイズタスクを非同期で実行します。 パブリッシャーとサブスクライバーは独立してスケーリングできます。 キューのサイズが大きくなると、処理時間を短縮するためにワーカーが追加されます。 ただし、ほとんどの場合キューが空の場合、ワーカーの数が減少する可能性があります。
数百万人以上のユーザー
システム拡張は無限ループです。 反復するたび、新しいことを学びます。 数百万人のユーザーに拡張するための新しい戦略では、より多くの調整が必要です。 たとえば、システムを最適化し、より均一なサブサービスに分割する必要がある場合があります。 このレッスンで学んだすべてのテクニックは、新しい問題を解決するための優れた基盤を提供します。 記事の最後に、調べたことの要約があります。
・ステートレスWebアーキテクチャ
・どこにでもバックアップを作成する
・可能な限りキャッシュする
・マルチデータセンターのサポート
・・CDNに静的リソースを保存する
・シャーディングを使用したデータのスケーリング
・複数のデバイスに階層を分割する
・システムを監視し、自動化ツールを使用する
オフショア開発でシステムをご検討されている方々はぜひ一度ご相談ください。
※以下通り弊社の連絡先
アカウントマネージャー: クアン(日本語・英語対応可)
電話番号: (+84)2462 900 388
メール:konnichiwa@hachinet.com
お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。
- オフショア開発
- エンジニア人材派遣
- ラボ開発
- ソフトウェアテスト
電話番号: (+84)2462 900 388
メール: contact@hachinet.com
お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。
無料見積もりはこちらから
Tags
ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。
関連記事
アプリとWeb、どっちが稼げる？収益化モデルの違いと選び方
アプリやWebサービスを通じて収益化を目指す企業やクリエイターが増える中、「アプリとWeb、どちらがより稼ぎやすいのか？」という疑問は、多くの人にとって無視できないテーマです。アプリ内課金やサブスクリプション、広告など、収益化の方法は多岐にわたり、それぞれに適したプラットフォームやユーザー体験があります。本記事では、「アプリ web 違い」という観点から、主要なマネタイズモデルの特徴を比較し、ビジネスの種類や目的に応じた最適な選択肢を探っていきます。
Web MVPからネイティブアプリへ：成功するアプリ戦略と効率的な市場検証の秘訣
新しいサービスやアプリを開発する際に、最初の一歩として「Web MVP（最小限の実用的製品）」を選ぶ企業が増えています。では、なぜ多くの企業がネイティブアプリではなく、まずWebから始めるのでしょうか？今回はその戦略的な背景や技術的な理由を詳しく解説します。
ゲームβテストで見逃されがちな小さなバグとユーザー体験の密接な関係とは？
ゲーム開発におけるβテストは、リリース前の重要なフェーズであり、バグの洗い出しやバランス調整など多くの目的があります。特に注目されがちなのは致命的なバグやゲームバランスの崩壊ですが、その裏で見逃されやすいのが「小さなバグ」です。たとえゲーム進行に支障がなくても、こうした微細な不具合がユーザー体験に与える影響は想像以上に大きいことがあります。本記事では、βテスト中に軽視されがちな小さなバグとユーザー体験（UX）との関係に焦点を当て、その見逃しがなぜ危険なのか、どのように対処すべきかを解説します。
有名ゲームに学ぶ！βテスト成功の秘訣と押さえるべき3つのポイント
ゲーム開発におけるβテストは、単なる不具合発見の場ではなく、ユーザーの体験や反応を直接把握し、製品の完成度や市場適合性を高める重要な工程です。特に有名タイトルの成功事例を分析すると、βテストはグローバル展開を見据えた多文化対応や、ユーザーの声を活かした改善サイクルの構築に役立っていることがわかります。本記事では、そうした成功事例を通じて、βテストをより効果的に運用するためのポイントを具体的に解説します。
ゲームβテストでバグ報告が増えない理由──UIがユーザーの声を封じている？
ゲームのβテストは、開発とユーザーが共に作品を育てる重要なフェーズです。しかし、いざテストを実施しても「思ったほどバグ報告が集まらない」と悩む開発者は少なくありません。実はその背景には、単なる不具合の有無ではなく、“レポートUIの設計”が大きく影響しているケースがあります。ユーザーが「報告したくてもできない」構造になっていないか。本記事では、ユーザー視点でのバグ報告行動と、それを左右するUI/UXの課題について掘り下げます。
炎上βテスト10選｜過去の失敗から学ぶ“やってはいけない”こと【ゲーム業界ジャーナリスト風考察】
ゲーム業界において「βテスト」は、ただの不具合検証にとどまらず、ユーザーの第一印象を左右し、時にはプロジェクト全体の評価を左右する重要なフェーズです。期待値の高い新作タイトルほど、そのテスト運営の良し悪しが注目されやすく、過去には些細なミスから大規模な炎上に発展したケースも少なくありません。本記事では、実際に炎上を招いたゲームβテストの失敗事例を10件紹介しながら、その共通パターンを分析し、今後のテスト設計において「やってはいけないこと」を明らかにしていきます。ゲーム開発者・運営担当者・マーケティング関係者の皆さまにとって、失敗から学ぶヒントとなれば幸いです。
感想か？データか？｜ゲームβテストの本当のKPIとは
現代のゲーム開発において「βテスト」は欠かせないプロセスとなっていますが、その目的を“ユーザーの感想を集めること”に限定してしまうと、本質を見失う危険があります。実際、感想がポジティブだったにもかかわらず、リリース後にユーザーの離脱や収益の伸び悩みが発生するケースは珍しくありません。本記事では、ゲームβテストにおける「本当のKPI」に注目し、感想と行動データの両面から“何を測り、どう改善すべきか”を明らかにします。これからβテストを設計・運用する方に向けて、実例を交えながら実践的な視点で解説していきます。