SAP BTPログ設計：3つのログの必要性と具体的な実現方法

SAPソリューション

こんにちは！SAP BTP（Business Technology Platform）を活用したクラウドネイティブなシステム開発が進む中で、避けて通れないのが「ログの設計と運用」です。

オンプレミスのシステムとは異なり、クラウド環境（特にマイクロサービス構造）では、アプリケーション、データベース、認証基盤などがバラバラに動いています。そのため、トラブルが起きたときに「どこで何が起きているのか」を中央集権的に把握できるログ基盤が不可欠です。

本記事では、システム運用やセキュリティで求められる「3つの主要なログ（業務ログ・エラーログ・監査ログ）」について、なぜそれらが必要なのかという目的を整理した上で、SAP BTPのどのサービスを使ってどのように実現するのか、そして実務で必ず直面する「ログの保持期間」と「長期保存方法」まで、初心者の方にも分かりやすく丁寧に解説します！

ログの3つの分類とその必要性

ログと一言で言っても、その目的によって出力すべき内容や管理方法は全く異なります。
まずは、今回対象とする3つのログが「誰のために」「何のために」必要なのかを整理しましょう。

業務ログ（アプリケーションログ）

  • 主な対象者： 運用担当者、ビジネスユーザー
  • 必要性： 「システムがビジネスの要件通りに正しく動いているか」を追跡するためのログです。例えば、「ユーザーAがログインした」「注文処理（ID: 12345）が開始され、無事に完了した」「バッチ処理で100件のデータを処理した」といった、正常系の動向を記録します。 これがないと、ユーザーから「処理ボタンを押したけれど、本当に動いている？」と問い合わせがあった際に、システムが裏で正しく動いたのかどうかを証明できなくなってしまいます。

エラーログ

  • 主な対象者： 開発者、運用保守担当者
  • 必要性： システムで予期せぬエラーや障害が発生した際、その根本原因を迅速に分析（RCA：Root Cause Analysis）するためのログです。 エラーが発生した画面のスクリプトエラーだけでなく、バックエンドのデータベース接続エラーや、外部APIとの通信タイムアウトなど、「どこで」「何が原因で」処理が落ちたのかを、エラーメッセージやプログラムのスタックトレース（プログラムの実行履歴）とともに記録します。これがないと、障害復旧やバグ修正に膨大な時間がかかってしまいます。

監査ログ（オーディットログ）

  • 主な対象者： セキュリティ管理者、内部・外部の監査人
  • 必要性： 「誰が、いつ、どのデータ（特に個人情報や機密情報）に対して、どのような操作（参照・作成・更新・削除）を行ったか」を厳格に記録するログです。 業務ログとの大きな違いは、「不正アクセスの検知」や「情報の持ち出し・改ざんの有無」を証明するというセキュリティ・コンプライアンス（内部統制やSOX法、GDPRなど）に特化している点です。そのため、監査ログは一般のシステム開発者が簡単に削除・改ざんできないような、安全性の高い専用の仕組みに保管する必要があります。

SAP BTPにおける各ログの実現方法と保持期間

ここからは、これらのログをSAP BTP上でどのように実現するのか、具体的なサービス名と、それぞれの「標準でのログ保持期間」を併せて見ていきましょう。

業務ログ・エラーログの実現：SAP Cloud Logging

  • 標準の保持期間： デフォルトは7日間（設定変更により最大90日間まで延長可能。ただしディスク容量による自動調整あり）

業務ログとエラーログは、どちらもアプリケーションの稼働状況を監視するためのもの（オブザーバビリティ：可視化）ですので、BTPでは「SAP Cloud Logging」というサービスに集約して管理するのが標準的なアプローチです。

【アプリケーション（CAPなど）】（標準出力にログを流すだけ）
　　　↓
(自動転送)
　　　↓
【SAP Cloud Logging】（ログの収集・蓄積）
　　　↓
【Kibanaダッシュボード】（検索・エラー率の可視化）

どうやって実現するの？

BTPでアプリケーションを開発する際（例：CAP – Cloud Application Programming Modelなど）、開発者は特別なログ送信プログラムを1から書く必要はありません。

  1. 標準出力にログを流す： Application（Node.jsやJava）の標準的なログライブラリを使って、コンソールにログを出力するコードを書きます。
  2. 自動で集約される： BTPの実行環境（Cloud FoundryやKyma）にアプリケーションをデプロイすると、アプリケーションが出力したログは、自動的に背後の「SAP Cloud Logging」へと転送・集約されます。
  3. Kibanaで分析する： SAP Cloud Loggingには、オープンソースで有名なデータ可視化ツール「Kibana（キバナ）」をベースとしたダッシュボードが標準で備わっており、キーワード検索やエラー発生率の可視化が簡単に行えます。

CAP（Java）での具体的なログ出力例

特にバックエンドを CAP（Java） で開発する場合、Javaの世界で広く使われている標準的なログライブラリ 「SLF4J」 と、その実装である 「Logback」 をそのまま活用できます。BTP専用の特殊なログコードを書く必要はありません。

Java

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.sap.cds.services.handler.EventHandler;
import com.sap.cds.services.handler.annotations.On;
import com.sap.cds.services.handler.annotations.ServiceName;
import org.springframework.stereotype.Component;

@Component
@ServiceName("OrderService")
public class OrderHandler implements EventHandler {

    // 1. SLF4Jのロガーを宣言
    private static final Logger logger = LoggerFactory.getLogger(OrderHandler.class);

    @On(event = "submitOrder")
    public void onSubmitOrder() {
        // 2. 業務ログ（INFO）の出力
        logger.info("注文処理を開始しました。");

        try {
            // 業務ロジックの実行...
        } catch (Exception e) {
            // 3. エラーログ（ERROR）の出力（スタックトレースも一緒に渡す）
            logger.error("注文処理中に予期せぬエラーが発生しました。原因: {}", e.getMessage(), e);
        }
    }
}

BTPがログを「構造化（JSON化）」してくれる

上記のJavaコードがローカル環境（PC）で動くときはテキスト形式ですが、BTPにデプロイすると、自動的に JSON（構造化）形式 へと変換されます。 logger（クラス名）、level（ログレベル）、msg（メッセージ内容）、correlation_id（相関ID）といったキーごとにデータが整理されるため、バックエンド側は何も意識せずとも、Kibanaで高度な分析やフィルタリングができる状態が整います。

監査ログの実現：SAP Audit Log Service

  • 標準の保持期間： 90日間（追加コストなしのデフォルト期間。プレミアムプラン等で設定変更も可能）

セキュリティやコンプライアンスのための監査ログは、業務ログとは明確に切り離し、BTPが提供する専用の「SAP Audit Log Service」を利用します。

【ユーザーのデータ操作】 （データの参照・更新など）
　　↓
【SAP Audit Log Service】（改ざん不可能な安全な領域）
　　↓ 
【Audit Log Viewer】　   （監査人向けの専用閲覧ツール）

どうやって実現するの？

SAP BTPの各プラットフォームサービス（ユーザー認証を司るSAP Cloud Identity Servicesなど）が「誰がログインしたか」といったログを自動的にこのサービスに記録してくれます。

アプリケーション開発（CAP）において、特定の機密データへのアクセスを監視したい場合は、CAPのデータモデル定義の中で、監査対象にしたいテーブルや項目に対して「これは個人情報（Personal Data）です」「監査対象（Audited）です」という設定（アノテーション）を付与します。 これだけで、データの参照（Read）や更新（Write）のイベントが、自動的に「SAP Audit Log Service」へ安全に送信され、BTP管理画面の「Audit Log Viewer」から閲覧可能になります。一番のメリットは、「ログの改ざんができないようにBTP側で強固に保護されている」点です。

ログを長期間保存（アーカイブ）する方法

ここまで説明した通り、BTPの標準機能におけるログの保持期間は「数日〜90日間」と、クラウド上の運用監視としては十分ですが、
企業のセキュリティポリシーや法的要件（「監査ログは7年間保持すること」など）を満たすには短すぎます。

そのため、システム設計時には必ず「長期保存（アーカイブ）」の仕組みを合わせて実装する必要があります。代表的な2つのアプローチをご紹介します。

アプローチA：BTP内の「Object Store」へファイルとして転送する

BTPが提供する低コストなストレージサービス 「Object Store Service」（実体はAWSのS3やAzure Blob Storageなど、選択したインフラのストレージ）を利用する方法です。

  • 仕組み： SAP Cloud Logging や SAP Audit Log Service には、ログデータを外部にエクスポートするためのAPI（Retrieval API等）が用意されています。これらを呼び出す定期バッチ処理（Job）をBTP上に作成し、1日1回などの頻度でログをテキストやJSONファイルとして抽出し、Object Storeへ保存します。
  • メリット： BTP環境内（同じグローバルアカウント内）で完結するため、ネットワークのセキュリティ設計がシンプルで、ストレージ費用を極めて安価に抑えられます。

アプローチB：企業の共通ログ基盤（SIEM・外部クラウド）へリアルタイム転送する

既に社内で統合的なログ管理基盤（SIEM：Security Information and Event Managementツールなど）を運用している場合に最適な方法です。

  • 仕組み： SAP BTPには 「SAP Alert Notification service」 や、各ログサービスの 「Log Forwarding（ログ転送機能）」 があります。これらを利用して、BTP側でログが発生した瞬間に、外部の Splunk、Datadog、あるいは自社が持つAWS/Azure上のログ集約基盤へとリアルタイムにログをストリーミング（転送）します。
  • メリット： 他の社内システム（オンプレミスのERPや周辺クラウドサービス）のログとBTPのログを「1つの画面で串刺しにして監視」できるようになります。長期保存の設定も、転送先（SplunkやS3など）のポリシーに委ねることができます。

まとめとログ設計のベストプラクティス

今回は、SAP BTPにおける3つのログの必要性、実現方法、そして保持期間と長期保存の対策について解説しました。

  • 業務・エラーログ： デフォルト7日（最大90日）。日々の運用は 「SAP Cloud Logging（Kibana）」 で行い、必要に応じて外部へ。
  • 監査ログ： デフォルト90日。セキュリティコンプライアンスのため 「SAP Audit Log Service」 で保護し、長期要件がある場合はAPI経由で 「Object Store」 や社内SIEMへ退避。

ログは「とりあえず出す」だけではなく、「何日間保持し、いざという時にどうやって検索するか」までをセットで設計することが、プロジェクトを成功させる大きなカギとなります。

皆さんのBTPプロジェクトでも、ぜひ最初の段階からこの「保持期間とアーカイブのシナリオ」を検討してみてください！

コメント

タイトルとURLをコピーしました