📄

システム方式設計はログから始めよ

2023/09/29に公開

こんにちは！
オアシステクノロジーズの古本です。

今日はシステム方式設計についてのお話です！

具体的には、ハードウェア構成やアプリケーション構成を決定したり、どういうソフトウェアを利用するのか、どういう外部連携が存在するのかなどを決めていきます。
ほかにも、機能要件を実現するためにどういう処理パターンが存在するのかを具体化し、それぞれの処理パターンをどのように実現するのかを検討したりします。

2.ログって何？

簡単に言うとシステムによって行われたさまざまな記録です。
具体的には下記のようなものですね

システムの起動や終了
利用者のログイン
どういうリクエストによって何の処理が起動したのか
エラーや障害の発生
設定の変更

これらが「業務ログ」「エラーログ」「通信ログ」「操作ログ」「アクセスログ」など、何を対象に記録をするのかによって複数のログファイルが生まれるわけです。
ログはハードウェアやOS、ミドルウェアやアプリケーションなど様々な要素から出力されます。

ここで重要なのが「トレーサビリティを担保する」という観点です。

3.トレーサビリティとは？

トレースとは「追跡」という意味であり、トレーサビリティとは「何がいつ誰によって何をどのように行ったのか」を追跡できるようにしようね！って意味です。
なぜトレーサビリティを担保しなければいけないのか？それは、以下のような目的です。

システムに不具合や障害が発生した際に、原因や影響の調査ができる情報を記録しておくため。
不正アクセスなどが発生した際に、誰がどういう操作を行って、どういう情報にアクセスしたのかなどの情報を記録しておくため。

特に社会的影響が大きいシステムにおいては、上記のような問題が発生した際にクライアントが報告責任を負う場合があるんですね。
過去の記録がなければ、報告ができずに行政指導などのペナルティを負う可能性があるわけです。

4.なぜログ設計から始めるべきなのか

ここから本日話したい本題となります。

私はシステム方式設計において、まずログ設計から着手するべきだと考えています。
上記のような問題に直面した時に、完全性や網羅性をもったログ(記録)が必要になるわけですね。
でも、ログって直接業務機能に影響するものじゃないんですよね。

個別な業務機能設計ではログ出力が無視されることが多い

たとえば、「ユーザ情報を更新する」って機能があったとします。
処理の中身としては以下のようなものになるでしょう(超ざっくりですが…)

更新ボタンを押下する
リクエストを受け取り、バリデーションチェックする。
DBのエンティティモデルにリクエストパラメータを格納する
エンティティモデルの内容をDBに反映する。
更新されたユーザに対してショートメッセージを送信して通知する。
処理結果を画面に表示する

このように、ログに情報を記録するっていうのは業務処理を実現する上では不要なことが多いんですね。
なので必要なログの出力が漏れてしまうことが多々あります。
ほかにも、前述の通り完全性や網羅性をもったログを記録するためには業務処理を実現する上で必要なパラメータだけでは不足してしまう情報とかもあるわけです。
業務処理の設計書はめちゃくちゃたくさん作られるので、情報が不足していることがわかった時に反映しようとすると手戻りの影響がはんぱないんですよね。

複数のアプリで構築されている場合、ユーザ操作との関連性がわからなくなる

最近のシステムは複数のアプリケーションで構成されることが多くあります。
例えばこんな感じです。

フロントエンドでUIを提供するアプリ(モバイルアプリやReactなどのWebアプリなど)
バックエンドで業務処理などのAPIを提供するアプリ(PHPやJavaなど)
業務処理を実現する上で利用している外部システム(使うことが多いのはAuth0とか、Stripeとか、twilioとか)

この時の処理フローはこんな流れになります

フロントアプリ -> ロードバランサー -> バックエンドアプリ -> 外部システム

じゃあ「ユーザ情報を更新する」ってリクエストを送信した際にどんなログが発生するかというと…

要素	ログ	内容
フロントアプリ	操作ログ	更新ボタン押下イベントを記録する
ロードバランサー	アクセスログ	どういうリクエストが発生して、どのインスタンスに処理を転送したのか記録する
バックエンドアプリ	アクセスログ	どういうクエストが発生したのかを記録する。
バックエンドアプリ	業務ログ	どういう業務処理を実行したのか記録する。
バックエンドアプリ	業務ログ	どうい外部通信が発生したのか記録する。
外部システム	サービス内のアクティビティ履歴	誰に対してメッセージを送ったのか記録する。

こんな感じで、1つの処理だけでもいろんなログ(記録)が存在していることがわかると思います。
システムを利用するのが1人だけだったら良いんですけど、基本的には複数の利用者がいろんな操作を行っているので…それらの関連性っていうのはちゃんと設計してないとわけわかんなくなっちゃうんですね。

問題が発生した際に「このユーザのこの操作に対応するログはどれなの？」っていうことを、複数のログをまたいで簡単に見られるようにしたいわけです。
これを実現するために「トレーシングID」って呼ばれるような全てのログを網羅的に関連づけられる項目をログに出力してたり、ログ管理ツールを採用してそちらで関連付けてもらったりするんですね。

なんで方式設計をログから始めるべきなの？

このように、ログっていうのはシステムとしてサービスを提供する上で網羅的な観点が必要になるわけです。
つまり、ログ設計が終われば6割くらいはシステム方式設計は終わってるって言っても良いかもしれません。

ちょっと6割は言い過ぎかもしれませんが、ログ設計をすると関連して以下が明確になるはずです。

ハードウェア構成
アプリケーション構成
利用するミドルウェア
処理フロー
アプリケーション内の各要素の責務
業務機能に現れない共通的に必要なパラメータ
業務機能に現れないログを収集するために構築しなければならない機能
認証情報の管理方法

システム方式設計を経験された方であれば、上記を見てもらうと6割くらい終わってるって感覚は理解してもらえるんじゃないかと思います。
つまり、システム方式設計はログ設計を主軸にして個別の方式を詳細化していくと網羅的で漏れや手戻りが少なくなるよ！ってことです。

最後に

業務機能の設計をやってると、ログに対する考慮はついつい見落としてしまうことが多いと思います。
また、システム方式設計においてもなぜか後回しにされることが多いのがログ設計です。。

しかし、ログ設計というのはシステムを提供するクライアントが社会的責任を果たすために必要不可欠なものです。
システム運用者の作業(調査・原因分析)効率の向上にも繋がります。
そしてログ設計を後回しにしていると、影響範囲の広さから痛い目をみます。

皆さんも方式設計に着手する際には、是非ログ設計から着手してみてください。
きっとプロジェクトメンバーみんなが幸せになれるはずです。