JD Retail Cloud mPaaS モバイル ログ回復の調査と実践

1.1.導入

モバイル オペレーティング システムは、開発者に機能豊富なログ コンポーネントを提供します。たとえば、Android Studio の Logcat ウィンドウには、ガベージ コレクション中に表示されるメッセージや、Log クラスを使用してアプリケーションに追加されたメッセージなどのシステム メッセージが表示され、開発者が効率的に開発するのに役立ちます。しかし、実稼働環境では、ユーザー (または上司) から、比較的わかりにくく再現が難しい問題 (クラッシュではない) が報告された場合、何をすべきか途方に暮れてしまうことがよくあります。現時点では、オンラインでの異常データのリアルタイム報告の助けを借りて、ユーザーのネットワーク環境がスムーズで、異常データが時間内に報告されることを祈るしかありません。しかし、このアプローチでは、常に幸運が続くという保証はありません。

したがって、現在の問題を解決するには、高性能なモバイル ログ システムを開発する必要があります。システムには、完全なログ情報、低いパフォーマンス損失、軽量 (ボリューム)、正確な検索などの特性が必要です。次に、モバイルログシステムの開発履歴を紹介します。

1.2.デザイン

モバイル ログ システムは、ログ ファイルのキャリアとして Linux システムによって提供される mmap を使用します。現在、業界で人気のある XLOG ログ コンポーネント、MMKV、Meituan Logan はすべてこのソリューションを採用しています。その最大の利点は、効率的な I/O、低損失、およびクロスプロセスの利点です。次に、mmapの基本的な導入について紹介します。

mmapとは何ですか?

オペレーティング システムは、カーネル モードとユーザー モードの 2 つの動作モードに分かれています。

• カーネルモードではオペレーティングシステムのプログラムを実行でき、ユーザーモードではユーザープログラムを実行できます。
• ユーザー状態 (つまりアプリケーション) は物理デバイス上で直接操作することはできません (Ps: 物理デバイス上で操作する、つまりデバイスの物理アドレスにデータを書き込む)。ハードディスク上の特定のデータセクションを読み取りたい場合、通常はハードディスク -> カーネル -> ユーザーの順に実行する必要があります。つまり、データを 2 回コピーする必要があり、非常に非効率的です。この問題を解決するために、メモリ マッピングの概念が登場しました。カーネル マッピングは mmap です。 Mmap はデバイスの物理アドレスをプロセスの仮想アドレスにマップします。ユーザーが仮想メモリを操作すると、物理デバイスを操作するのと同等となり、カーネルからユーザーへのデータコピーが削減され、データスループットが向上します。

Linux では、mmap を使用して、プロセスの仮想メモリ アドレス空間にアドレス空間を割り当て、物理メモリとのマッピング関係を作成できます。

mmap を使用してファイルをプロセスにマップした後、読み取りや書き込みなどのシステム コールを呼び出さなくても、この仮想アドレスを直接操作してファイルの読み取りや書き込みを行うことができます。ただし、このメモリセグメントに直接書き込む場合、現在のファイルサイズを超える内容は書き込まれないことに注意してください。

つまり、mmap は従来のファイルの読み取りおよび書き込みとは異なり、次のような利点があります。

• データコピーの回数を減らし、I/Oの読み取りと書き込みをメモリの読み取りと書き込みに置き換え、ファイルの読み取り効率を向上させます。
• ユーザー空間とカーネル空間間の効率的な相互作用モードが実現されます。 2 つの空間の変更操作は、マップされた領域に直接反映されるため、時間内に他の空間に取り込むことができます。
• プロセスがメモリを共有し、相互に通信する方法を提供します。親子プロセスであっても、無関係なプロセスであっても、独自のユーザー空間を同じファイルにマップしたり、匿名で同じ領域にマップしたりできます。このように、マッピング領域を変更することで、プロセス間通信やプロセス間共有の目的を達成できます。
• 同時に、プロセス A とプロセス B の両方が領域 C をマップする場合、A が初めて C を読み取るときに、ページ フォールトを介してファイル ページをディスクからメモリにコピーします。しかし、B が C の同じページを再度読み取ると、ページ フォールト例外も発生しますが、ディスクからファイルをコピーする必要はなく、メモリにすでに保存されているファイル データを直接使用できます。
• 効率的な大規模データ伝送を実現できます。メモリ領域の不足は、ビッグデータの操作を制限する要因の 1 つです。解決策としては、多くの場合、ハードディスク領域を使用して操作を支援し、メモリ不足を補うことになります。ただし、これにより大量のファイル I/O 操作が発生し、効率に大きな影響が出ます。この問題は mmap マッピングによってうまく解決できます。つまり、メモリではなくディスク領域が必要なときはいつでも、mmap を使用できます。

1.2.2. mmapの使用

モバイル ログ収集 SDK の主なタスクは、ユーザーが書き込んだデータをファイルに保存することです。このプロセスでは、ネイティブ レイヤーで mmap 関数を呼び出して、プロセスの仮想メモリ アドレス空間にアドレス空間を割り当て、物理メモリとのマッピング関係を作成します。

次に、Linux システムでの mmap メカニズムの使用プロセスを紹介します。

mmap 関数

• 関数宣言

void* mmap(void* __addr, size_t __size, int __prot, int __flags, int __fd, off_t __offset);

• 戻り値の説明

正常に実行されると、mmap() はマップされた領域へのポインターを返します。失敗した場合、mmap() は MAP_FAILED [(void *)-1] を返し、error は次のいずれかの値に設定されます。

1. EACCES: アクセス エラー
2. EAGAIN: ファイルがロックされているか、メモリが多すぎる
3. EBADF: fd は有効なファイル記述子ではありません
4. EINVAL: 1 つ以上のパラメータが無効です
5. ENFILE: 開いているファイルのシステム制限に達しました
6. ENODEV: 指定されたファイルが存在するファイルシステムはメモリマッピングをサポートしていません
7. ENOMEM: メモリ不足、またはプロセスがメモリマッピングの最大数を超えました
8. EPERM: 権限が不十分なので、操作は許可されません
9. ETXTBSY: ファイルを書き込みモードで開き、MAP_DENYWRITEフラグを指定します。
10. SIGSEGV: 読み取り専用領域への書き込みを試行しました
11. SIGBUS: プロセスに属していないメモリ領域にアクセスしようとしました。

• パラメータの説明

モバイルコードでの mmap の使用

//ファイルの書き込みに使用するバッファ
静的unsigned char *_buffer = NULL ;
 // mmap キャッシュファイルのサイズ
静的  mmap_cache_fileは100*1024 です。 
 
 void init() {
  //ステップ1: 設定されたキャッシュの場所に基づいてマッピング用のファイルを生成する
  キャッシュパスを作成します。
  //ステップ2: キャッシュファイルを開く
int fd =オープン(cache_path、O_RDWR | O_CREAT、S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
  //mmapでマップされたファイルの判定
  if(fd != -1) {
     ......
    //ステップ3: mmapはファイルをバッファメモリにマップします
    _buffer = (unsigned char *) mmap(0, size , PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  }
  //ステップ4: ファイルハンドルを閉じる
閉じる（fd）;
 } 
 
 //ステップ5: mmapメモリの読み取りと書き込みを操作する
void 書き込み(....) {
  // 書き込むデータをカプセル化し、圧縮し、暗号化する
  データ圧縮
 
  // mmapキャッシュをファイルに書き込む
  fwrite(_buffer, sizeof( char ), _buffer.length, dest_file);
  fflush(dest_file); 
 
  // ファイルサイズの変更とその他の関連操作
アップデート（）;
 }

ログ書き込みプロセス

1.2.3.モバイルログシステムアーキテクチャの紹介

クライアント ログ SDK は、主にオンライン操作中に生成されたログをファイルに書き込むログ印刷機能、開発者のニーズに応じて指定されたログを取得する機能、開発者がオンラインの問題を解決する機能などを開発者に提供します。基本的な機能を満たすシステムを設計しました。アーキテクチャは次の図のようになります。

1.2.4.クライアントログ SDK の概要

ログ SDK のアーキテクチャを図に示します。これは次の 3 つのレイヤーに分けられ、それぞれが異なるビジネス シナリオを解決します。

ログ SDK は、最下層でストリーミング圧縮および暗号化操作を使用します。書き込まれたログデータを受信すると、データはまず圧縮され、その後暗号化されます。プロセス全体はストリーミング操作であるため、CPU ピークが回避され、CPU パフォーマンスへの負担が軽減されます。具体的な実装では、ログ損失の問題を解決するために MMAP メカニズムが導入され、ログのセキュリティを確保するためにログの暗号化に AES が使用されます。

ログ SDK は、サーバーによって発行された戦略を通じてローカル ログを動的に報告します。ここでは、最新の戦略を定期的に取得したり、プッシュ チャネルを通じてローカル戦略を更新したり、ユーザー フィードバックを通じてユーザーがログ データを報告できるようにするレポート インターフェイスを提供したりできます。現在、発行されたポリシーには多くのカスタマイズが施されており、ファイル サイズ、キャッシュ期間、ログ書き込みレベルなどの関連設定が発行されています。アプリケーションが初期化された後、開発者が使用するために必要なログのみをフィルタリングしてファイルに書き込みます。

ログ SDK は、ポリシーに従って、指定されたログ ファイルを指定されたサーバーにアップロードします。サーバーはアップロードされたログを解凍してデコードし、ログ ファイルを元の入力データに復元します。具体的なプロセスについては、以下の業務プロセスを参照してください。

SDKビジネスプロセスのログ

ログ SDK のビジネス プロセスを次の図に示します。サーバーに設定されたポリシーに従って、指定されたログが収集され、データの圧縮と暗号化が実行されます。その後、ローカル ログ ファイルがトランジット サービスにアクティブにアップロードされ、アップロード結果やその他の関連情報が情報が表示されるサーバーに同期されます。

SDK パフォーマンスのログ記録

上記の設計と使用では、CPU とメモリの消費を抑えるために、ストリーミング圧縮、暗号化、キャッシュなどの操作をネイティブ レイヤーに転送する mmap テクノロジを使用します。 Java レイヤー ログ ライブラリと比較して、メモリと CPU の使用量をどの程度削減できますか?次に、Java レイヤー ログ ライブラリを使用して、mmap を使用して実装されたネイティブ ライブラリと比較します。

テスト条件

パフォーマンス テストでは、同じ Xiaomi Note3 Android 9 スマートフォンを使用して、既存の Java ログ ライブラリ、現在のログ ライブラリ、Meituan Logan、および Tencent XLog ログ ライブラリの書き込みパフォーマンスをテストしました。ログ ライブラリの書き込みパフォーマンスは、書き込み速度、GC 頻度、CPU 使用率によって測定されます。テスト結果は現在のテスト環境の測定に限定されており、Android プラットフォームの全体的な平均レベルを表すものではありません。

テストデータ量:

テスト結果

1. メモリGCテスト結果

Java ロギング ライブラリ:

ネイティブ ログ ライブラリ:

上記のメモリパフォーマンスグラフから、Java ログライブラリは大量のログを書き込むときに頻繁に GC を引き起こすことがわかります。ネイティブ ログ ライブラリでは GC がそれほど頻繁に発生することはありませんが、図から、Java ログ ライブラリの GC 頻度は約 1 秒/回、ネイティブ ログ ライブラリの GC 頻度は約 7.5 秒/回であることがわかります。

2. CPU使用率テストの結果

Java ロギング ライブラリ:

ネイティブ ログ ライブラリ:

上記の CPU パフォーマンス グラフから、Java ログ ライブラリが頻繁にログを書き込む場合の平均 CPU 使用率は約 13% であり、ネイティブ ログ ライブラリが頻繁にログを書き込む場合の平均 CPU 使用率は約 5% であることがわかります。

上記のメモリと CPU 使用量の比較から、ネイティブ ログ ライブラリは Java ログ ライブラリに比べてパフォーマンスが大幅に向上していることがわかります。頻繁な I/O 操作や暗号化および圧縮操作の場合でも、占有メモリが少なくなり、CPU 使用率が低く抑えられます。

ロギングライブラリのパフォーマンスの比較

上記では、Java ログと比較しました。次に、mmap を使用して実装された他のログ ライブラリと比較します。

1.3.実例

アプリのオンライン環境ではさまざまな問題が発生する可能性があります。問題が発生した日のログを入手して、問題を分析し、解決に役立てたいと考えています。このようなビジネス シナリオは、ほぼすべてのビジネス シナリオをカバーします。セルフサービスレジなどの機器の使用シナリオでは、操作中のログがトラブルシューティングに特に重要です。

Shuke のセルフサービス チェックアウト機器は、主に大手スーパーマーケットの簡単なチェックアウトに役立ち、複数の手動チェックアウト チャネルでは相殺できないチェックアウトの負担を軽減します。問題が発生した場合、再度ユーザーを訪問することは不可能であるため、運用中のログはトラブルシューティングに特に重要です。

モバイル ログ システムを使用する前は、問題が発生した場合、運用ツールが不足していたため、問題のトラブルシューティングに多くの研究開発リソースが必要でした。モバイル ログ システムに接続すると、運用側でほとんどの問題を自力で処理できるようになります。これにより、問題解決の効率が大幅に向上し、R&D 側が運用上の問題のトラブルシューティングに費やす時間が短縮されます。

1.4.最後まで書きなさい

現在の SDK の使用シナリオは、サーバーの戦略を定期的に取得し、発行された最新の戦略に従ってログ ファイルを報告することです。ある程度の時間遅延があります。今後は、アクティブ ログ レポート用のチャネルを開設し、プッシュ メッセージと組み合わせて、ログ取得の適時性と成功率を向上させる予定です。

現在の SDK はモバイル端末 (Android および iOS) のみをサポートしています。今後は複数の端末をサポートし、RN、Flutter、ミニプログラム、H5 などのさまざまなアプリケーション シナリオでのログ収集と保存に現在のログ ライブラリを使用する予定です。