アプリ開発におけるスケーラビリティとは？

成長すると、見えていなかった弱点が表れる

変化が徐々に来ることもあります。アプリが少し遅く感じられ、問い合わせが増え、リリースの日が緊張するものになります。

突然来ることもあります。キャンペーンが広がり、報道でアクセスが集中し、社会的な目的を持つプロジェクトがニュースレターで紹介される。1日500人の利用者が5万人になります。1年かけてではなく、一週末でです。

プロジェクトで分かるのは、スケーラビリティが重要になるのは、技術への関心より、信頼を守りたいときであることが多いということです。負荷でアプリが不安定になると、単なるエラー以上のことが起きます。利用者が離れ、評価が下がり、チームは緊急対応に入ります。

期待は厳しいものです。モバイルのウェブ体験でも、待つ余裕の少なさが分かります。読み込みに3秒以上かかるページでは、53%以上が離脱します。Marketing Dive（Googleの2016年の調査）↗

アプリとウェブサイトは完全に同じではありませんが、感情の仕組みは共通です。すぐ動かなければ、信頼できないと感じます。

Polaからの一つ目の視点は、スケーラビリティは、社会への効果を安定して届ける力でもあるということです。より多くの人に届けたい教育アプリや、寄付を動かすプラットフォームなら、安定性は技術だけの問題ではありません。責任の一部です。ログイン処理の過負荷で、目的の実現が止まってはいけません。

そのためPolaでは、早くから簡単ですが重要な問いを立てます。アプリは、予測できる成長、予測できない集中、それとも両方に備える必要がありますか？この違いによって、後に処理容量、伸縮性、堅牢性のどれを優先するかが決まります。

利用負荷とプロダクトの複雑さは、別々に増える

スケーラブルなアプリが必要というとき、多くの人は、同時に使う人を増やしたいという意味で話します。重要ですが、話の半分にすぎません。

スケーラビリティには、二つの成長軸があります。

一つ目は、負荷の増加です。同時リクエスト、通信量、端末、プッシュ通知・同期・アップロードなどのバックグラウンド処理が増えます。アプリ市場は拡大し、問題なく動くことへの期待も高まります。その密度だけでも圧力が分かります。2023年には、Google Play Storeに370万以上、Apple App Storeに約180万のアプリがありました。Selleo↗

二つ目は、機能の増加です。新しい機能、役割、連携、市場が加わります。5画面で始まったアプリも、やがてルールや特別なケース、例外を持つプロダクトになります。多くの問題はここで起きます。CPUが弱いからではなく、変更するたびにリスクが高まるからです。

違いを明確にする必要があります。スケーラビリティと性能は同じではありません。性能は、ある負荷のもとでどれだけ速いかを示します。スケーラビリティは、負荷が増えたときに性能をどれだけ維持できるかを示します。

私たちがよく使う例えがあります。性能は、空いている線路で列車がどれだけ速く走るかです。スケーラビリティは、乗客が急に3倍になっても、ドアが詰まらず、信号が止まらず、運行全体が停止せずに、ダイヤを維持できるかです。

二つ目の視点は、スケーラビリティは、チームが働きやすいアーキテクチャでもあるということです。実際には、アプリだけでなく、担当チームも増えます。複数の開発者が並行して変更を届けるなら、変更同士を切り離す構造が必要です。スケーラブルなアプリとは、テストしやすく、モジュール化され、理解しやすいアプリでもあります。

早くから二つの軸を言葉にすると、判断しやすくなります。まず負荷の余力が必要なプロジェクトもあれば、機能を増やすための整理された基盤が必要なものもあります。両方が必要なことも多いですが、重みづけは明確にします。

四つの問いで、余力を具体化する

十分とは何かを定めなければ、スケーラビリティは感覚の話になります。そのため、私たちは早くから、日常業務でも役立つ形に整理します。

実務で試してきた方法を、社内ではFour-Question Testと呼んでいます。プロジェクトの中で忘れられないよう、意図的に簡単にしています。

1）最も重要な瞬間は何ですか？例えば、登録、決済、寄付の完了、データのアップロードです。

2）その重要性を数字で表すと？例えば、500の同時セッション、毎秒50リクエストと、応答時間の目標です。

3）どこまでのコストを許容できますか？金額だけでなく、運用の複雑さも含みます。

4）うまくいかないと、何が起きますか？売上、信頼、社会への効果が失われるかもしれません。

ここから、数字に埋もれず監視できる指標が見えてきます。レイテンシ（応答時間。できれば95パーセンタイル）、スループット（毎秒のリクエスト数）、エラー率（タイムアウト、5xx、クラッシュ率）、そしてリクエストあたりのコストです。

なぜコストも見るのでしょうか。見ないと、拡張で気づかないうちに費用が増えるからです。よいスケーラビリティは、サーバーを増やし続けることではなく、投入する資源あたりの性能を高めることです。見落とされがちな投資効果がここにあります。効率のよいアプリはクラウド費用を節約し、エネルギー消費も減らします。

事業面では、現実の例が役立ちます。小さな遅延でも費用につながります。Amazonは社内で、100ミリ秒の追加遅延が売上に1%影響し得ると観察したとされています。LinkedInの投稿（Amazonの見解を再引用）↗

こうした数字は、圧力をかけるためではなく、優先順位を明確にするために使います。重要な瞬間がコンバージョンなら、スケーラビリティは技術の追加要素ではなく、価値を生む仕組みを守るものです。

実務で差を生む点もあります。測れることは、安心にもつながります。監視と負荷テストがあれば、期待するだけでなく、状況を知ることができます。

アクセス集中は、最も狭い箇所にぶつかる

負荷でアプリが止まると、外からはサーバーの過負荷という一つの問題に見えます。実際には、ほとんどの場合、複数のボトルネックが連なっています。

典型的なのは、データベースです。最初は、情報が一か所にまとまり、整合性があり、追跡もできて便利です。やがて、一つのクエリが急に千倍実行される、ロックが書き込みを妨げる、適切でないインデックスが検索を全体の走査に変えてしまう、といったことが起こります。

同じくらいよく問題になるのが、コードです。処理自体が遅いというより、結びつきが強すぎます。一つの関数が別の三つを呼び、外部APIを待ち、その間に同期的にログを書きます。50人なら動いても、5,000人では連鎖的な問題になります。

最初にはあまり語られないボトルネックもあります。手順とリリースです。修正を夜にしか反映できず、デプロイが怖く、公開後に何を監視するか誰も把握していないなら、拡大するのはシステムではなくストレスです。

三つ目の視点は、スケーラビリティは、障害に対応しやすいことでもあるというものです。増加だけでなく、うまくいかないときのためにも作ります。堅牢なアプリには、明確な境界、タイムアウト、代替手段があります。チームが状況をすばやく理解する助けにもなります。

実務では、すぐに使える小さな原則を大切にしています。「重要な処理は短くする」ことです。登録、決済、寄付などの重要な瞬間には、依存関係をできるだけ少なくします。その後のメール送信、PDF生成、統計更新は、非同期で行います。

これで、障害の費用が大きい理由も分かります。停止は技術の状態だけでなく、事業上の損失です。Atlassianは、大企業の障害が数千万規模の損失を生んだ例を紹介しています。Atlassian↗

この影響を感じるのはFacebookのような企業だけではありません。小さなプロダクトは、余裕がさらに少ないだけです。

性能を増やすことと、台数を増やすことは、別の問題を解決する

拡張の話では、すぐに二つの基本モデルが出てきます。垂直拡張と水平拡張です。

垂直拡張は、一つのシステムの性能を増やすことです。CPU、RAM、データベースの構成を大きくします。すばやく実施でき、構造変更も少ないため、最初の一歩になることが多いです。ただし限界があります。やがて費用が高くなり、故障し得る中心点も残ります。

水平拡張は、複数のインスタンスに負荷を分けることです。一台を強くするのではなく、台数を増やします。理想的には、集中時に自動で増やし、静かな時間には減らします。

通常、水平拡張には二つの要素が必要です。通信を振り分けるロードバランサーと、ステートレスなサービスです。難しく聞こえますが、意味は簡単です。セッションをサーバーAに保存していてログインがAでしか動かなければ、Bは助けられません。一方、状態を共通の保存先、例えばデータベースやRedisのようなキャッシュに置けば、どのインスタンスでも処理を引き受けられます。

実際には、組み合わせることが多いです。少し垂直拡張して余裕を作り、重要な箇所を狙って水平拡張します。

私たちが常に意識するのは、信頼性とスケーラビリティは近い関係にあるということです。水平拡張を始めると、冗長性も組み込むことが多くなります。一つが止まっても、ほかが引き継ぎます。性能だけでなく、リスクも改善します。

ここにPolaの考え方があります。常に最大の性能を用意するより、システムに伸縮性を持たせます。必要なときだけ資源を追加すると、費用と不要なエネルギー消費を減らせます。無駄にしないという姿勢の技術的な表現です。

始めたばかりなら、最も重要な判断はKubernetesを使うかどうかではありません。アプリが基本的に複数のインスタンスで動けるかです。ここを適切に準備すれば、多くの選択肢を残せます。

成り立つ中で最もシンプルな道が、最適なことは多い

アーキテクチャの議論は、モノリスが悪く、マイクロサービスがよいという固定観念に寄りがちです。私たちは別の見方をします。多くのプロダクトでは、最初は適切に作られたモノリスが合います。実装、テスト、理解がしやすいからです。

問題はモノリスそのものより、境界のないモノリスです。すべてが相互に依存すると、どの変更も高くつきます。

そこで、もう一つの実践的な方法を使います。「技術ではなく、責任で分ける」ことです。早くから業務の領域で構成を分け、後に一部を切り出すとき、プロダクト全体を壊さずに済むようにします。

典型的な進め方は次の通りです。

• アカウント、コンテンツ、決済など、明確な領域を持つモジュール型モノリスで始めます。
• ある領域が大きく成長したり、特別な要件を持ったりしたら、独立したサービスに切り出します。
• チームと運用に実際の利点がある段階で、複数の独立サービスにします。

なぜこの順序なのでしょうか。マイクロサービスは部分ごとの独立運用を可能にしますが、ネットワーク通信、分散した処理のデバッグ、バージョン管理、可観測性という新しい仕事も増やします。既にある複雑さに対応するためなら価値がありますが、複雑さを自ら増やすためには使いません。

スタートアップの文脈からの注意点も当てはまります。失敗の大きな割合が、早すぎる規模拡大に関係するという指摘があります。主に組織や戦略の話ですが、考え方は応用できます。LinkedInの投稿（Startup Genomeの数値を再引用）↗

私たちの姿勢は、入り口を計画し、最初から家全体を建てないことです。MVPで始めてもかまいません。ただし、成長のたびに作り直さなくてよい構造にします。

こうした判断をさらに知りたいなら、アプリのプロジェクトでも同様の設計課題を支援してきました。後から機能や利用者層を追加したUrekaやAeriなどが例です。状況は毎回違いますが、規模より明確さを優先する原則は共通です。

キャッシュと処理の分離で、必要な余力を作る

スケーラブルなアプリを実用的に改善するとき、最初から大きな改修をすることは少ないです。狙いを絞ったいくつかの要素で、すぐに安定性を高められます。資源の無駄も減るため、持続可能な考え方にも合います。

キャッシュは、最初に使うことが多い要素です。同じトップページを1万人が開くなら、同じ処理を1万回するべきではありません。例えばRedisのようなキャッシュは、よく使うデータをメモリに保存し、データベースとバックエンドの負荷を軽くします。

CDNも定番です。画像や素材、場合によってはAPI応答の一部を、利用者の近くから配信できます。応答時間を短くし、中心のシステムの負荷も減らします。多くのチームにとって、Cloudflareは、CDN、キャッシュ、保護機能を組み合わせやすい、すばやく始められる選択肢です。

キューは、アクセス集中を予測できないときに私たちが好む要素です。すべてを即座に処理しようとせず、タスクを受け付け、バックグラウンドで処理します。負荷の山を平らにし、システムを待てるものにします。技術的には、RabbitMQや、より大きな規模ならApache Kafkaなどで実現できます。

さらに、データベースの対策があります。読み取り性能を高めるレプリケーション、適切なインデックス、場合によってはパーティショニングです。マイクロサービスほど華やかではありませんが、実際に改善が進むきっかけになることは多いです。

この順序は決まりではなく、経験によるものです。まず分かりやすい非効率を改善し、その後に分散します。

Polaの視点では、環境に配慮した成長は、よいエンジニアリングの結果であることが多いのです。必要なときだけ拡張する設計は、通常、安く、常に最大規模で動くシステムよりエネルギーも少なく使います。Scandも、負荷が増えたときだけ資源を追加する、資源効率としてスケーラビリティを説明しています。Scand↗

目的を重視して取り組むなら、これは目立たなくても大切な点です。プロダクトが成長しても、運用が常に燃え続けるように膨らむ必要はありません。

テストしなければ、耐えられるという想定にとどまる

スケーラビリティは、作る段階だけでなく、特に運用で形になります。体制は整っているはずなのに、集中時に必要だったテスト、通知、明確な手順が欠けていたチームを、何度も見てきました。

負荷テストはぜいたくに聞こえますが、実際には最も安く現実を確認できる方法の一つです。Miquidoも、アプリが成長に耐えられるかは、負荷テストと性能テストで初めて分かると実用的に説明しています。Miquido↗

現在の開発パイプラインに合うツールなら、私たちはk6を好んで使います。スクリプトで書けて、自動化しやすく、結果も明確です。従来型の構成なら、JMeterやGatlingも頼れる選択肢です。

監視も必要です。CPUの使用率だけでなく、どのエンドポイントが遅くなり、どのデータベースクエリが負荷を占め、どこでエラー率が上がっているかを見ます。そのために、指標、ログ、分散システムならトレースを含む可観測性が必要です。実績のあるオープンソースの組み合わせは、PrometheusとGrafanaです。より早く始めたいなら、DatadogやNew Relicが実用的なこともあります。

次は障害への備えです。本当に問題が起きたら、どうするのでしょうか。

私たちは簡単に保ち、チームと三つのことを練習します。

1）リリース後は観察する。最初の30分に、どの指標を確認しますか？

2）通知は行動につながるものにする。無視される大量の通知より、適切な少数の通知が有効です。

3）ロールバックも機能として備える。戻すのが難しいと、すべての更新がリスクになります。

Polaの仕事は、公開で終わりません。性能、保守性、運用を一緒に考えます。日常業務に安心をもたらして初めて、スケーラビリティは実際のものになるからです。その安心は、利用者が言葉にできなくても感じる品質です。