モバイルインターネットの時代には、モバイルアプリを介してデータをアップロードすることがますます一般的になっています。 モバイルアプリのログは、アプリサーバーによって転送されるのではなく、Log Service に直接アップロードすることができるため、ユーザーはビジネスロジックの開発に集中することができます。
通常モードでは、認証と改ざん防止のために Log Service にログを書き込むときに、Alibaba Cloud アカウントの AccessKey が必要となります。 モバイルアプリがこのモードで Log Service にアクセスする場合は、AccessKey 情報をモバイルクライアントに保存する必要があります。これにより、AccessKey が開示されるデータセキュリティリスクが生じます。 AccessKey が開示されたら、モバイルアプリをアップグレードし、AccessKey を交換する必要がありますが、これはコストがかかりすぎます。 モバイルクライアントから Log Service にログをアップロードするもう 1 つの方法は、ユーザーのアプリサーバーを使用することです。 ただし、このモードでは、モバイルアプリの数が多い場合に、アプリサーバーはモバイルクライアント上のすべてのデータを処理する必要があります。 このモードには、サーバーの仕様に関する高い要件があります。
上記の問題を回避するために、Log Service は、モバイルアプリのログを収集するためのより安全で便利なスキームを提供しています。 RAM を使用して、モバイルサービスに基づくモバイルアプリ用の直接データ転送サービスを構築します。 AccessKey を直接使用して Log Service にアクセスするスキームとは異なり、このスキームではアプリ側に AccessKey を格納する必要はありません。 これにより、AccessKey が開示されるリスクが排除されます。 ライフサイクルを備えた一時トークンを使用すると、より安全になります。 たとえば、IP アドレスセグメントのアクセス許可を制限するなど、トークンに対してより複雑なアクセス制御ポリシーを設定することもできます。 このスキームのコストは低いです。 モバイルアプリはクラウドプラットフォームに直接接続され、制御フローのみがアプリサーバーに送信されるため、多くのアプリサーバーは必要ありません。
Log Service を操作するための RAM ロールを作成し、RAM ユーザーとしてアプリを設定してこのロールを引き受けることができるため、30 分以内にモバイルアプリ用の Log Service ベースの直接ログ転送サービスを構築することができます。 直接データ転送は、モバイルアプリが Log Service に直接アクセスできるようにするサービスで、制御フローのみがアプリサーバーに送信されます。
利点
RAM を使用してモバイルアプリ用の Log Service ベースの直接データ転送サービスを構築すると、次の利点があります。
- このアクセスモードはより安全で柔軟であり、一時的な権限の割り当てと認証を提供します。
- アプリサーバーが少なくて済むため、コストを削減することができます。 モバイルアプリはクラウドプラットフォームに直接接続され、制御フローのみがアプリサーバーに送信されます。
- Log Service は高い同時実行性をサポートしています。 多数のユーザーが同時にサービスを使用することができます。 大きなアップロードおよびダウンロード帯域幅が提供されます。
- Log Service は自動スケーリングをサポートし、無制限のストレージスペースを提供します。

説明
モジュール | 説明 |
---|---|
Android または iOS モバイルアプリ | エンドユーザーの携帯電話上のアプリとログソースです。 |
LOG | アプリがアップロードしたログデータを保存する Alibaba Cloud Log Service です。 |
RAM または STS | Alibaba Cloud RAM は、ユーザー ID 管理とリソースアクセス制御サービスを提供し、一時的なアクセス認証情報を生成します。 |
アプリサーバー | Android または iOS アプリ用に開発されたアプリバックグラウンドサービスです。 アプリがデータのアップロードとダウンロードに使用するトークンと、アプリ内のユーザーがアップロードしたデータのメタデータ情報を管理します。 |
設定プロセス
- アプリはアプリサーバーからの一時的なアクセス認証情報を申請します。
情報漏えいのリスクを回避するために、Android または iOS アプリは AccessKey ID および AccessKey Secret を保存しません。 したがって、アプリはアプリサーバーに一時的なアップロード認証情報 (トークン) をリクエストする必要があります。 トークンは一定の期間のみ有効です。 たとえば、トークンが 30 分間有効になるように設定されている場合は (アプリサーバーで指定可能)、Android または iOS アプリはこのトークンを使用して、次の 30 分以内に Log Service にアクセスすることができます。 ただし、30 分後、アプリは新しいトークンを要求する必要があります。
- アプリサーバーはリクエストの有効性を確認してから、アプリにトークンを返します。
- トークンを取得すると、モバイルアプリは Log Service にアクセスすることができます。
本ページでは、アプリサーバーが RAM service からトークンを適用する方法と、Android または iOS アプリがトークンを取得する方法について説明します。
手順
1. Log Service を操作するための RAM ロールを承認します。
Log Service を操作するための RAM ロールを作成し、このロールを引き受ける RAM ユーザーとしてアプリを設定します。 詳細については、「ユーザーロール」をご参照ください。
設定が完了すると、次の情報を取得することができます。
- RAM ユーザーの AccessKey ID とAccessKey Secret
- ロールのリソースパス
2. アプリサーバーを構築します。
本ページでは、複数の言語のサンプルプログラムを提供します。 ダウンロード URL は、本ページの最後にリストされています。
ダウンロードした各言語パッケージには、次の情報を含む設定ファイル config.json が含まれています。
{
"AccessKeyID" : "",
"AccessKeySecret" : "",
"RoleArn" : "",
"TokenExpireTime" : "900",
"PolicyFile": "policy/all_policy.txt"
}
- AccessKeyID: AccessKey の ID です。
- AccessKeySecret: AccessKey のシークレットです。
- RoleArn: ロールのリソースパスです。
- TokenExpireTime: Android または iOS アプリによって取得されたトークンの有効期限を示します。 最小値は秒単位で 900 です。 デフォルト値のままにすることができます。
- PolicyFile: トークンが付与できるアクセス許可をリストするファイルです。 デフォルト値を変更する必要はありません。
本ページでは、ポリシーディレクトリで最も一般的な権限を定義する 2 つのトークンファイルについて説明します。
- write_policy.txt: このユーザーにプロジェクトの書き込み権限を付与するトークンを指定します。
- readonly_policy.txt: このユーザーにプロジェクトの読み取り権限を付与するトークンを指定します。
必要に応じて、ポリシーファイルを設計することもできます。
レスポンスフォーマット
// Correct response
{
"StatusCode":200,
"AccessKeyId":"STS.3p***dgagdasdg",
"AccessKeySecret":"rpnwO9***tGdrddgsR2YrTtI",
"SecurityToken":"CAES+wMIARKAAZhjH0EUOIhJMQBMjRywXq7MQ/cjLYg80Aho1ek0Jm63XMhr9Oc5s˙∂˙∂3qaPer8p1YaX1NTDiCFZWFkvlHf1pQhuxfKBc+mRR9KAbHUefqH+rdjZqjTF7p2m1wJXP8S6k+G2MpHrUe6TYBkJ43GhhTVFMuM3BZajY3VjZWOXBIODRIR1FKZjIiEjMzMzE0MjY0NzM5MTE4NjkxMSoLY2xpZGSSDgSDGAGESGTETqOio6c2RrLWRlbW8vKgoUYWNzOm9zczoqOio6c2RrLWRlbW9KEDExNDg5MzAxMDcyNDY4MThSBTI2ODQyWg9Bc3N1bWVkUm9sZVVzZXJgAGoSMzMzMTQyNjQ3MzkxMTg2OTExcglzZGstZGVtbzI=",
"Expiration":"2017-11-12T07:49:09Z",
}
// Error response
{
"StatusCode":500,
"ErrorCode":"InvalidAccessKeyId.NotFound",
"ErrorMessage":"Specified access key is not found."
}
正しい応答の説明: 次の表は、トークンを構成する 5 つの変数を示しています。
変数 | 説明 |
---|---|
StatusCode | アプリがトークンを取得したときに返される結果です。 トークンが正常に取得されると、アプリは 200 を返します。 |
AccessKeyId | Android または iOS アプリが LogClient の初期化するときに取得する AccessKey ID です。 |
AccessKeySecret | Android または iOS アプリが LogClient を初期化するときに取得する AccessKey secret です。 |
SecurityToken | Android または iOS アプリが Log Service へのアクセスに使用するトークンです。 |
Expiration | トークンの有効期限が切れるまでの期間です。 Android SDK は、自動的にトークンの有効性を判断し、必要に応じて新しいトークンを取得します。 |
エラー応答の説明:
変数 | 説明 |
---|---|
StatusCode | アプリがトークンを取得したときに返される結果です。 トークンの取得に失敗した場合は、アプリは 500 を返します。 |
ErrorCode | エラーの原因です。 |
ErrorMessage | エラーの説明です。 |
サンプルコードの実行方法:
Java 1.7 以降の場合は、パッケージをダウンロードして解凍した後、Java プロジェクトを作成し、依存関係、コード、および設定をプロジェクトにコピーして、main 関数を実行します。 デフォルトでは、プログラムはポート 7080 を再生し、HTTP リクエストを待ちます。 同様の方法で、他の言語の操作を実行します。
3. モバイルクライアントが HTTP リクエストを作成して、アプリサーバーからトークンを取得します。
HTTP リクエストと応答のフォーマットは次のとおりです。
Request URL: GET https://localhost:7080/
Response:
{
"StatusCode":"200",
"AccessKeyId":"STS.XXXXXXXXXXXXXXX",
"AccessKeySecret":"",
"SecurityToken":"",
"Expiration":"2017-11-20T08:23:15Z"
}
ソースコードのダウンロード
アプリサーバーのサンプルコード: 『PHP、Java、Ruby、Node.js』