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 は次のいずれかの値に設定されます。

EACCES: アクセスエラー
EAGAIN: ファイルがロックされているか、メモリが多すぎる
EBADF: fd は有効なファイル記述子ではありません
EINVAL: 1 つ以上のパラメータが無効です
ENFILE: 開いているファイルのシステム制限に達しました
ENODEV: 指定されたファイルが存在するファイルシステムはメモリマッピングをサポートしていません
ENOMEM: メモリ不足、またはプロセスがメモリマッピングの最大数を超えました
EPERM: 権限が不十分なので、操作は許可されません
ETXTBSY: ファイルを書き込みモードで開き、MAP_DENYWRITEフラグを指定します。
SIGSEGV: 読み取り専用領域への書き込みを試行しました
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 側が運用上の問題のトラブルシューティングに費やす時間が短縮されます。