モバイルインターネットの時代には、モバイルアプリを使用したデータアップロードがますます普及しています。モバイルアプリのログは、アプリサーバーによって転送されるのではなく、Log Service 直接アップロードされるため、ユーザーはビジネスロジックの開発にもっと集中することができます。
通常モードでは、認証と改ざん防止のために Log Service にログを書き込むときに、プライマリアカウントのアクセスキーが必要です。モバイルアプリがこのモードで Log Service にアクセスする場合、アクセスキーをモバイル側に保存する必要があり、アクセスキーの公開に関するデータセキュリティリスクが発生します。AccessKey が公開されたら、モバイルアプリをアップグレードして AccessKey を交換する必要がありますが、これはかなり高価です。モバイル側のログをログサービスにアップロードするもう 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 モバイルアプリ | エンドユーザーの携帯電話で実行されているアプリ、ログのソース。 |
ログ | Alibaba Cloud Log Service は、アプリケーションによってアップロードされたログデータの保存を担当します。詳細については、Alibaba Cloud Web サイトの 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 からトークンを適用する方法と、Android/iOS アプリケーションのトークンを取得する方法について説明します。
手順
1. Log Service を操作するユーザーロールを認可します。
Log Service RAM ユーザーロールを作成し、RAM サブアカウントとしてこの役割を果たすアプリケーションを構成します。詳細については、Log Service を操作するユーザーロールを認可するを参照してください。
設定後、次のパラメータを取得できます。
- RAM サブアカウントの AccessKey ID と AccessKey Secret
- ロールのリソースパス RoleArn
2. アプリケーションサーバーを設定します。
このチュートリアルでは、複数の言語でサンプルプログラムを提供しています。ダウンロード URL は、このドキュメントの最後に記載されています。
ダウンロードされた各言語パッケージには、次の構成ファイル config.json が含まれています。
{
"AccessKeyID" : "",
"AccessKeySecret" : "",
"RoleArn" : "",
"TokenExpireTime" : "900",
"PolicyFile": "policy/write_policy.txt"
}
注意:
- AccessKeyID: AccessKey の ID。
- AccessKeySecret: AccessKey の秘密。
- RoleArn: ユーザーロールの RoleArn。
- TokenExpireTime: Android/iOS アプリで取得したトークンの有効期限。最小値は 900 秒であり、変更する必要はありません。
- PolicyFile: トークンが許可するアクセス許可を列挙したファイル。デフォルト値は変更する必要はありません。
このドキュメントでは、ポリシーディレクトリで最も一般的なアクセス許可を定義する 2 つのトークンファイルを提供しています。
- write_policy.txt:プロジェクトの書き込み権限をこのアカウントに許可するトークンを指定します。
readonly_policy.txt:このアカウントへのプロジェクトの読み込み権限を与えるトークンを指定します。
必要に応じてポリシーファイルを設計できます。権限の詳細については、Log Service 権限制御を参照してください。
返されるデータの形式:
//Returned correct result
{
"StatusCode":200,
"AccessKeyId":"STS.3p***dgagdasdg",
"AccessKeySecret":"rpnwO9***tGdrddgsR2YrTtI",
"SecurityToken":"CAES+wMIARKAAZhjH0EUOIhJMQBMjRywXq7MQ/cjLYg80Aho1ek0Jm63XMhr9Oc5s˙∂˙∂3qaPer8p1YaX1NTDiCFZWFkvlHf1pQhuxfKBc+mRR9KAbHUefqH+rdjZqjTF7p2m1wJXP8S6k+G2MpHrUe6TYBkJ43GhhTVFMuM3BZajY3VjZWOXBIODRIR1FKZjIiEjMzMzE0MjY0NzM5MTE4NjkxMSoLY2xpZGSSDgSDGAGESGTETqOio6c2RrLWRlbW8vKgoUYWNzOm9zczoqOio6c2RrLWRlbW9KEDExNDg5MzAxMDcyNDY4MThSBTI2ODQyWg9Bc3N1bWVkUm9sZVVzZXJgAGoSMzMzMTQyNjQ3MzkxMTg2OTExcglzZGstZGVtbzI=",
"Expiration":"2017-11-12T07:49:09Z",
}
//Returned error//
{
"StatusCode":500,
"ErrorCode":"InvalidAccessKeyId.NotFound",
"ErrorMessage":"Specified AccessKey is not found."
}
返された正しい結果の説明、次の 5 つの変数はトークンを構成します。
変数 | 説明 |
---|---|
StatusCode | アプリがトークンを取得した結果。トークンが正常に取得された場合、アプリは 200 を返します。 |
AccessKeyId | ログクライアントを初期化するときに Android/iOS アプリが取得する AccessKey ID。 |
AccessKeySecret | AccessKey Android/iOS アプリがログクライアントを初期化するときに取得する秘密。 |
SecurityToken | Android/iOS アプリが初期化するトークン。 |
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"
}
このドキュメントのすべての例は、サーバーのセットアップ方法を示すために使用されています。これらの例に基づいてカスタム開発を実装することができます。
ソースコードをダウンロードする
アプリケーションサーバーのサンプルコード