スケーラブルなモバイルアプリ・インフラを構築するには?

Mobile App Infrastructure
Mobile App Infrastructure

モバイルアプリケーションのインフラを拡張したいですか?ここでは、モバイル・アプリケーション・インフラを拡張する方法について、実際の教訓を詳しく説明します。

モバイルアプリとは何か?

モバイルアプリとは、スマートフォンやタブレット、腕時計などのモバイルデバイス上で動作するアプリケーションのこと。モバイルアプリには、ネイティブアプリ、ハイブリッドアプリ、ウェブアプリなど複数の種類があります。

  • ネイティブアプリは、AndroidやiOSのような特定のオペレーティングシステムで動作する;
  • ウェブアプリは、HTML5やCSSといった技術を使ってコーディングされる;
  • ハイブリッド・アプリはウェブ・アプリのように動作するが、ネイティブ・コンテナ内にフレーム化されている。

モバイルアプリのインフラストラクチャー・アーキテクチャーの詳細については、続きをお読みください。

ウェブアプリ vs ハイブリッドアプリ vs ネイティブアプリ

スケーラブルなアプリ・アーキテクチャーの定義とは?

スケーラブルなアーキテクチャを定義する際には、多くの変数が不可欠である。

大規模でスケーラブルなモバイル・アプリケーションは、何千、何百万もの利用をサポートする可能性が高く、パフォーマンス、信頼性、安全性が求められる。

つまり、クラス最高のアーキテクチャは、ダウンタイムがなく、クラッシュがなく、読み込み速度が速く、最先端のセキュリティを備えているということだ。

本記事では、これらの要素を考慮し、モバイルアプリ向けのスケーラブルなバックエンドインフラを提案する。

モバイルアプリのインフラはどうなっているのか?

モバイル・アプリケーション・アーキテクチャを構成する要素はいくつかあるが、以下にモバイル・アプリケーションに必要なインフラを示す。

  • アプリ公開プラットフォーム
  • SDK – ソフトウェア開発キット
  • API
  • CDN – コンテンツ・デリバリー・ネットワーク
  • オブジェクト・ストレージ
  • ロードバランサー
  • アプリケーションサーバー
  • データベースサーバー

スケーラブルなモバイル・アプリ・アーキテクチャと、上記の各レイヤーについて詳しく知りたい方は、このまま読み進めてください。

モバイルアプリ・アーキテクチャ

アプリ公開プラットフォーム

さまざまなテクノロジーを使ってモバイルアプリケーションを構築することが可能だ。SwiftやKotlin/JavaのようなiOSやAndroidのネイティブ開発言語から、React NativeやFlutterのようなクロスプラットフォーム開発フレームワークまで。

上述したテクノロジーは、モバイル・アプリケーションのフロントエンドやクライアント側のインターフェイスを作成する。Google PlayやApp Storeのようなアプリケーション・ストアは、エンドユーザーにモバイル・アプリケーションを配布するためのエコシステムを提供する。

開発者は、これらのパブリッシング・プラットフォームにモバイルアプリを提出し、レビューを待つ必要がある。

Google PlayとApp Storeにはそれぞれ異なる公開ガイドラインがあり、アプリの公開を妨げる可能性のある問題を避けるためには、まずガイドラインを読むことが不可欠です。

アプリケーションストアの精査を避けるために、React、Angular、Ionicなどの技術を使ったPWA(Progressive Web Applications)を開発するという選択肢もある。

SDK – ソフトウェア開発キット

ソフトウェア開発キットは、スケーラブルなモバイルアプリのインフラを構築する上で不可欠なステップだ。SDKは、API、ライブラリ、デバッガ、ドキュメントなどのツールを備えたインストール可能なパッケージで構成される。

モバイル・バックエンドSDKには、バックエンドとフロントエンド間のインターフェイスを橋渡しする要素が含まれている可能性が高い。

わかりやすい例は、バックエンドからフロントエンドへのプッシュ通知の送信です。SDKはこのアクションを容易にし、機能要素の統合を加速します。

API – アプリケーション・プログラミング・インターフェース

APIはモバイルアプリのアーキテクチャを開発する上で欠かせない要素だ。APIは、フロントエンド(クライアントサイド)とモバイルアプリケーションのバックエンド(サーバーサイド)を接続するソフトウェアインターフェースである。

モバイルアプリのバックエンド実装でAPIを使用する利点には、タスクの自動化、機能のカスタマイズ、柔軟な情報配信、新しいサービスの配布などがある。

API - モバイル・アプリケーション・インフラ

CDN – コンテンツ・デリバリー・ネットワーク

CDNとは、高速なコンテンツ配信を実現するために連携する、地理的に分散したサーバー群のことである。これらのサーバーはエンドユーザーにより近い場所に配置され、インターネットコンテンツ(画像、動画など)を読み込むための資産の高速転送を可能にする。

CDN実装のその他の利点としては、最適なルーティングによるモバイルアプリのクライアントサイドとサーバーサイド間の通信時間の短縮、帯域幅コストの削減、セキュリティ(DDoS攻撃、証明書など)が挙げられる。

オブジェクト・ストレージ

モバイルアプリのインフラストラクチャーのこの要素は、CDNに接続し、ファイルストレージ、ビデオストレージ、画像ストレージなどを包含する。CDNはコンテンツをキャッシュし、エンドユーザーに最も近い場所への配信時間を短縮する。

ロードバランサー

モバイルアプリのインフラを構築する上で、次のレイヤーはロードバランサーだ。クラウドコンピューティングでは、ロードバランサーはタスクをサーバー群に分散させ、全体の処理を効率化する。

CDNはロードバランサーに接続し、ロードバランサー・ソフトウェアはクライアント側のリクエストを効率的に分配し、高可用性を確保し、需要に応じてスケールアップ/ダウンする。

アプリケーションサーバー

モバイル・アプリケーション・アーキテクチャの構築における次のステップは、アプリケーション・サーバーだ。このインフラはビジネス・ロジックを処理し、データベース・サーバーとCDNの中間に位置する。

データベースサーバー

モバイル・アプリケーションのインフラ構築の最終段階は、データベース・サーバーの構築だ。データベース・クラスターは、保存されたデータを保存・操作する高性能インスタンスで構成される。

データベース・インフラは冗長であることもあれば、そうでないこともある。冗長アーキテクチャでは、少なくとも2つのインスタンスがリアルタイムでデータを同期する。

モバイル・アプリケーションを拡張するには?

スケーラブルなアプリケーション・インフラを構築するには、主に2つの方法がある。1つ目はMobile Backend as a Serviceのようなマネージド・サービスを利用する方法、2つ目はInfrastructure as a Serviceプロバイダーを使ってバックエンドをゼロから作る方法だ。

BaaSサービスを利用すると、すぐに使えてスケーラブルなインフラ、バックエンド開発を加速させるすぐに使えるビルディング・ブロック、サーバーサイドとクライアントサイドの統合を効率化するSDKが提供される。一般的に、バックエンドプラットフォームを使用すると、アプリのスケーリングが容易になります。

バックエンドをゼロから開発すれば、開発者はインフラ要素のほとんどをより柔軟にコントロールできる。その一方で、バックエンドを管理し、ワークロードに応じてインフラをスケールアップしたりスケールダウンしたりする必要がある。

この2つのオプションについて、それぞれ詳しく見ていこう。

BaaS – サービスとしてのバックエンド

BaaSを使ったモバイル・アプリケーションのバックエンドのスケーリングは非常に簡単で、この目標を達成するためのすべての要素が整っている。BaaSプラットフォームの中核事業は、手間がかからず安全でスケーラブルなアーキテクチャを顧客に提供することだ。

Back4Appのようなバックエンド・プロバイダーの中には、ほんの数分でバックエンドを作成できるところもある。最初のステップは、サインアップして最初のアプリに名前を付けることだ。

スケーラブルなバックエンド - Back4app Login

次のステップは完全に自動化され、プラットフォームはデータモデル、アプリケーションサーバー、スケーリングポリシー、バックアップ、セキュリティをわずか数分で提供する。

スケーラブルなバックエンド - アプリを作成するBack4app

次の画面では、データモデル、サーバーレス機能、API、インフラ設定を包含するGUI(グラフィカル・ユーザー・インターフェイス)が提供される。

スケーラブルなバックエンド - Back4app dashboard

バックエンドはすぐに使用でき、スケーラビリティが組み込まれている。ユーザーが行うことは、SDKを介してアプリケーションのフロントエンドをバックエンドに接続し、データをアップロードし、ビジネスロジックをコーディングすることだけである。

Back4Appは、React Native、Flutter、Android、iOS、Javascript、Xamarinなど、すぐに使えるSDKを多数提供しています。

スケーラブルなバックエンド - Back4app SDKs

Back4Appを使って最初のアプリケーションを作成する方法をより詳しく知りたい方は、チュートリアル「Create Your First App With Back4App」をご参照ください。

モバイルアプリ・インフラのスケーリングの実例

以下は、モバイルアプリのインフラを拡張するためにBackend as a Serviceを使用する利点に関する2つの実例である。

  • Broadcast

最初の例は、ノルウェーの新興企業Broadcast Osloだ。この会社は、オスロで開催されるフェスティバル、コンサート、クラブの無料ガイドを提供している。

Broadcastosloはモバイル・ファーストのアプリケーションで、Google PlayとApp Storeの両方でアプリを配信している。ユーザーはダウンロードし、今後数ヶ月間にオスロで開催されるすべての将来のイベントにアクセスすることができます。

このアプリケーションは、ユーザーがリアルタイムでフェスティバルのスケジュールにアクセスすることも可能で、インフラのスケーラビリティの課題はここから始まる。

Musikkfest Oslo 2022は6月4日に開催され、約2万人が参加した。つまり、何千人ものユーザーが同時にアプリにアクセスし、データを取得することをサポートするために、インフラがどれほどスケーラブルでなければならないかを想像してみてほしい。

Broadcastの技術チームはこの問題を解決するためにBack4Appを使用することにしました!BroadcastのCEOであるTim Harris氏のコメントです。

アプリへのアクセスに問題がなかったことはとても重要だった!

ティム・ハリス、Broadcast 社CEO
  • Fight List

Fight Listは1,000万ダウンロードを超え、Two4Teaによって作成された非常に成功したゲームです。7カ国語以上で配信され、アメリカやフランスではトップランキングにランクインしています。

このゲームには高度なスケーリングの課題があり、何千人ものユーザーが同時にアプリにアクセスする必要がある。

Two4Teaはインフラの課題を解決するためにBack4appを選択し、ピーク時に毎秒10k以上のリクエストを処理しました。以下は、Two4TeaのCEOであるNicolas Boulch氏のコメントです。

この時、Back4Appが私たちのアプリを特別に分析し、カスタムソリューションを構築してくれたので、私たちはBack4Appが正しい選択だと気づきました。

ニコラ・ブールシュ、Two4TeaのCEO

Fight Listのスケーリングの課題については、Back4Appを使ったゲームのスケーリングの記事をご覧ください。

主要クラウドプロバイダーでカスタムバックエンドを構築

スケーラブルなモバイル・アプリケーション・インフラを構築する2つ目の選択肢は、AWS、Google Cloud、Azure、Digital Oceanなどのクラウド・プロバイダーを使ってバックエンドを構築することだ。

このセットアップを採用する利点は、主に柔軟性、バックエンドインフラストラクチャの制御性、各プロセスステップの可視性にある。

デメリットは、バックエンドインフラの構築と保守、定型的なバックエンドコードの開発、24時間体制でのシステム監視など、エンジニアの努力に依存していることだ。

AWSは世界中で最も利用されているクラウド・プロバイダーだ。このベンダーを使って、スケーラブルなモバイル・アプリケーションのバックエンドを作る手順を説明しよう。

最初のステップは、AWS のアカウントを作成してアクティブにすることです。チュートリアルHow do I create and activate a new AWS accountに従ってください。

次のステップは、バックエンドの実装をサポートする製品を定義することである。この例では以下を使用する:

  • EC2インスタンス
  • EBS – Elastic Block Storage
  • S3 – シンプル・ストレージ・システム
  • ロードバランサー
  • CDN – CloudFront

各ステップをさらに詳しく見ていこう。

EC2インスタンスの作成

スケーラブルなバックエンド・インフラストラクチャには、アプリケーションとデータベースの仮想マシンが必要になる。最初のステップは、クラスタ上で使用するインスタンスモデルを定義することだ。

AWSは多くのユースケースに最適化された複数のインスタンスタイプを提供している。そのリストには、汎用、コンピュート最適化、メモリ最適化、アクセラレーテッド・コンピューティング、ストレージ最適化インスタンスが含まれる。

この例では、汎用インスタンスを使用します。Armベースのアーキテクチャを提供するt4g.mediumインスタンスから始めましょう。バースト可能なワークロードに最適で、時間あたりの価格もお得です。

以下は、最初のステップである:

  • AWSへのログイン
モバイルアプリケーションのインフラを拡張する - ログイン AWS
  • EC2へ
  • インスタンス
スケーラブルなバックエンド - インスタンスの作成
  • 新しいインスタンスを立ち上げる
スケーラブルなバックエンド - インスタンスの起動

このステップでは、オペレーティング・システム、インスタンス・タイプ、サイズ、ネットワーク設定、インスタンスへのブロック・ストレージの追加、セキュリティ設定などを定義しなければならない。

EC2インスタンスのセットアップの詳細については、チュートリアルのEC2インスタンスの作成と起動に従ってください。

サーバークラスタの準備が整い次第、次のステップではワークロードに基づいてスケーリングポリシーを設定する。

サーバー・クラスタのスケーリングには、水平スケーリングと垂直スケーリングの2つの方法がある。

  • 水平スケーリング – 新しいワークロードに対応するためにクラスタにインスタンスを追加します。
  • 垂直スケーリング– 新しいワークロードに対応するため、インスタンスにリソース(CPU/RAM)を追加する。

一般的に言って、アプリケーション・サーバーは水平スケーリングを優先的なスケーリング・メカニズムとして使用する。データベース・クラスタは垂直スケーリングを好んで使用する。

アプリケーションクラスタの水平スケーリングは、一般的に簡単なプロセスだ。AWSを使用してそれを行う方法は、Auto Scalingメニューにアクセスし、新しいコンフィギュレーションを起動することだ。

データベースの垂直スケーリングは、インスタンスをシャットダウンしてインスタンスサイズを変更することができないため、より複雑なプロセスとなる。この方法では、クラスタはダウンタイムに直面することになる。

正しい方法は、より大きなインスタンスを新たに作成し、データを同期させ、ワークロード処理をより大きなインスタンスに転送することだ。ロケット・サイエンスではないが、このプロセスを自動化するには時間がかかる。

アプリケーションのワークロードが増大し、データベースの垂直スケーリングがもはや不可能になった場合、複数のインスタンスにワークロードを分散させることが唯一の道となる。これは複雑な実装であり、最後のオプションとしてのみ使用されるべきである。

EC2に自動スケーリングを追加する方法の詳細な手順については、チュートリアルのGet started with Amazon EC2 auto scalingに従ってください。

EBS – Elastic Block Storage

各インスタンスには、アタッチされたEBSボリュームが必要です。ただし、ストレージがハードウェアに組み込まれているエフェメラル・インスタンスは例外です。

これは、仮想マシンの初期設定中に行う簡単なステップです。課題は、不要なコストを回避し、データを保存するのに十分な容量を確保するために、適切なEBSサイズを決定することです。

正しいEBSタイプを選択することも不可欠である。SSDや磁気ディスクなど、多くのEBSオプションがある。適切なEBSタイプを選択することは、パフォーマンスとコストのバランスを保証するために不可欠である。

EBSボリュームを仮想マシンにアタッチする方法の詳細については、Amazon EBSボリュームをインスタンスにアタッチするを参照してください。

S3 – シンプル・ストレージ・サービス

堅牢でスケーラブルなバックエンドインフラにはオブジェクトストレージが必要だ。AWSでそれを実現するのは簡単なことで、S3はこの目標を達成するための理想的な製品だ。

S3バケットを作成する最初のステップは、ファイルを保存するリージョンを定義することだ。一般的には、EC2インスタンスと同じリージョンを選択する。

スケーラブルなモバイルアプリのインフラ - S3バケットを構築。

作成プロセスの一環として、オブジェクトの所有権、公開アクセスルール、バケットのバージョニング、暗号化の要件を定義する必要がある。

AWS S3バケットはデフォルトでスケーラブルであり、ユーザーは使用したリソースに対してのみ料金を支払う。S3バケットの作成に関する追加情報については、チュートリアルのCreating an S3 bucketに従ってください。

ロードバランサー

スケーラブルなインフラには、正しいロードバランサーの実装が必要だ。AWSは製品の一部としていくつかのタイプのロードバランサーを提供している。

アプリケーションのロードバランサーは、リクエストを適切なEC2インスタンスにルーティングし、これらのインスタンスの健全性を監視する。

ロードバランサーをインスタンスにアタッチするのは複雑なプロセスではなく、以下のステップでできる:

  • EC2のダッシュボードに移動する
  • ロードバランシング
  • ロードバランサー
  • ロードバランサータイプを選択
モバイルアプリインフラのスケーリング - ロードバランサータイプ。
  • ロードバランサーのIPアドレスタイプ、VPC、アベイラビリティゾーン、アドオンサービスを設定する。

ロードバランサーのセットアップ方法の詳細については、チュートリアルGetting started with application load balancer を参照してください。

Cloudfront CDN

Cloudfrontは、AWSで利用可能な組み込みのコンテンツ配信ネットワークで、世界中の約300のエッジロケーションをサポートしている。この製品は、静的および動的なコンテンツ配信を高速化し、セキュリティを向上させ、他のAWS製品との統合が容易です。

スケーラブルなバックエンドアーキテクチャの一部として、CloudfrontはS3バケットやロードバランサーと接続する。

ユーザーはEC2ダッシュボードを介してCloudfrontをロードバランサーに接続し、ロードバランサーを作成し、グループをターゲットにし、Cloudfrontディストリビューションを設定することができる。詳細はEC2向けのCloudfrontディストリビューションの設定に記載されている。

CloudfrontをS3バケットに接続するのも簡単だ。接続はCloudfrontダッシュボードから行い、Cloudfrontディストリビューションを作成し、オリジンドメインを追加する。詳細はブログポストCreating AWS CloudFront Distribution with S3 Originを読んでください。

結論

モバイル・アプリケーションは、携帯電話、タブレット、時計などのデバイス上で動作する。最も一般的な実装は、ネイティブアプリ、ハイブリッドアプリ、ウェブアプリです。

スケーラブルなモバイル・アプリケーション・インフラは、ダウンタイムやクラッシュがなく、超高速でセキュアであるように設計されたシステムで構成される。

スケーラブルなインフラに不可欠な要素には、アプリ公開プラットフォーム、SDK、API、CDN、ロードバランサー、アプリケーションサーバー、データベースサーバーなどがある。

クラス最高のスケーラブルなモバイルアプリインフラを実現する最も一般的な2つの方法は、Backend as a Serviceのようなレディ・トゥ・ソリューションを使用するか、AWSのようなクラウドサービス上でオーダーメイドのバックエンドをセットアップすることだ。

サービス・ソリューションとしてのバックエンドは、より迅速な実装、すぐに使えるスケーリング機能、定義済みのセキュリティ・プロトコルを提供する。一方、カスタムメイドのバックエンドは、より柔軟な環境とコントロールを提供する。

この記事をお読みいただき、優れたモバイルアプリのアーキテクチャの基礎について理解を深めていただけたなら幸いです。バックエンドの作成、メンテナンス、スケーリングに煩わされたくない方は、ぜひBack4Appにご相談ください。

よくあるご質問

モバイルアプリとは?

モバイルアプリケーションは、携帯電話、タブレット、スマートウォッチなどのデバイスで動作します。最も一般的な実装は、ネイティブアプリ、ハイブリッドアプリ、Webアプリです。

モバイルアプリのインフラストラクチャはどのようなものですか?

スケーラブルなインフラストラクチャの基本要素には、アプリ配信プラットフォーム、SDK、API、CDN、ロードバランサー、アプリケーションサーバーおよびデータベースサーバーが含まれます。

スケーラブルなモバイルアプリのインフラストラクチャを構築するには?

最先端でスケーラブルなモバイルアプリのインフラストラクチャを実現する一般的な方法は、Backend as a Service のような既製のソリューションを使用するか、AWS のようなクラウドサービス上にカスタムバックエンドを構築することです。


Leave a reply

Your email address will not be published.