はじめに
Azure Storage Account の設計を題材として、自身が実践した技術課題解決のプロセスを振り返る。
自分自身の行動指針や、フレームワーク的な考え方を他者へ伝えるときに、普段から言語化していないと、いざ話すときに言葉が出てこないと思ったためである。
なお、本記事の目的は Azure Storage Account の設計手法を解説することではない。
実際の検討を通して、
- 課題をどのように整理したか
- どのような観点で比較したか
- どのように意思決定したか
を振り返ることを目的とする。
課題
Azure Storage Account にログを長期保管する構成を検討していた。
Storage Account のネットワーク公開方式として、以下の選択肢が存在した。
- パブリックアクセス
- パブリックアクセス（送信元制限）
- パブリックアクセス無効（Private Endpoint 利用）
今回保管対象となるログは、通常時の参照頻度は高くないものの、障害調査や監査対応などで参照・ダウンロードする可能性がある。
Azure Storage Account ではデータプレーン（実際にデータが格納されている層のようなイメージ）に対してネットワーク的に到達可能でなければ、Azure Portal や CLI からデータへアクセスできない。
そのため、
- セキュリティ
- ログ参照時の運用性
- 構築および運用の複雑さ
を考慮しながら、どの公開方式を採用するか判断する必要があった。
実施した課題解決フロー
① 実現可能性の洗い出し
まずは各選択肢について、
「どのように設計すればログ参照を実現できるか」
を整理した。
この段階では方式の優劣は判断せず、実現するために必要な構成や追加設計を洗い出すことを目的とした。
重要なのは、
「どれが良いか」
を決めることではなく、
「そもそも実現できない案は存在するのか」
を明確にすることである。
実現できない案が混ざったまま比較検討を進めると、後工程での調査や設計のやり直しが発生するためである。
パブリックアクセス
- インターネット経由でアクセス可能
- Azure Portalからログ参照可能
- 追加構成は不要
パブリックアクセス（送信元制限）
- 許可したIPアドレスからのみアクセス可能
- Azure Portalからログ参照可能
- 保守拠点など許可IPの設計が必要
Private Endpoint利用
- プライベートネットワーク経由のみアクセス可能
- ログ参照経路を別途設計する必要がある
- 今回の構成ではWindowsサーバが存在しなかったため、Linuxサーバ経由でCLIからアクセスする構成が現実的であった
各案を整理した結果、いずれの方式も技術的には実現可能であることが分かった。
② 実運用でのメリット・デメリットを整理
実装可能なことが分かったため、次に実際の運用を想像した。
お客様から明示的に提示されていた要件ではなかったが、ログという性質上、
- 障害調査
- 問い合わせ対応
- 監査対応
などで参照される可能性がある。
そこで、
「実際に利用する場合どうなるか」
という観点で各案を比較した。
パブリックアクセス
メリット
- インターネット接続可能な環境であればどこからでも参照可能
- Azure PortalからGUIでアクセス可能
- 接続元を意識する必要がない
- 運用担当者への説明が容易
デメリット
- ネットワークによるアクセス制御ができない
- 認証情報の管理に依存したセキュリティとなる
パブリックアクセス（送信元制限）
メリット
- 許可された拠点からのみアクセスできる
- Entra認証とネットワーク制御による多層防御が可能
- Azure PortalによるGUI操作が可能
- 運用性とセキュリティのバランスが良い
デメリット
- 保守拠点のIPアドレス管理が必要
- 緊急時に許可されていない環境から参照できない
- 接続元変更時に設定変更が必要
Private Endpoint利用
メリット
- アクセス経路をプライベートネットワークに限定できる
- インターネット経由のアクセスを排除できる
- ネットワーク面で最も強固な構成となる
デメリット
- ログ参照経路の設計が必要
- Azure Portalから直接参照する運用が難しい
- Linuxサーバ経由でCLI操作を行う運用となる可能性が高い
- ログ確認時の操作負荷が高い
- 利用者教育が必要
③ 総合評価
ここまでの検討を通して、各方式は技術的には実現可能であることが分かった。
一方で、
「実現可能であること」
と
「採用すべき方式であること」
は別の問題であることも分かった。
実現可能性の洗い出しでは、
- どの方式でもログ参照を実現できること
- ただし、実現のために必要な追加設計や構成が異なること
が分かった。
また、実運用でのメリット・デメリット整理では、
- セキュリティレベル
- GUIによる参照可否
- 運用担当者の負荷
- 構成の複雑さ
によって運用性が大きく変化することが分かった。
そのため、今回の検討では以下の3点を主要な評価軸とした。
- セキュリティ
- 運用負荷
- 追加設計工数
まず、セキュリティの観点では Private Endpoint 利用が最も優れていた。
しかし、ログ参照経路の設計や Linux サーバ経由での CLI 操作が必要となるため、運用負荷および追加設計工数は最も大きくなることが想定された。
また、GUIによるログ参照を実現することも可能ではあるが、今回のシステムではログ参照は日常的な運用ではなく、障害調査や監査対応時など限定的な利用を想定していた。
そのため、長期保管ログの参照のためだけに追加のアクセス環境や運用基盤を整備することは、費用対効果の観点で過剰設計であると判断した。
一方、パブリックアクセスは追加設計がほとんど不要で運用もしやすい構成であったが、ネットワークレベルでアクセスを制御できないという課題があった。
そこで、
- 必要なセキュリティを確保できること
- Azure Portal から GUI でログ参照できること
- 運用時に特別な手順や環境を必要としないこと
を重視して各方式を評価した。
その結果、
パブリックアクセス（送信元制限）
が最もバランスの良い選択肢であると判断した。
この方式であれば、
- Azure Portal による GUI アクセスを維持できる
- Entra 認証に加えてネットワーク制御を実施できる
- Private Endpoint ほど大きな追加設計を必要としない
という特徴を持つためである。
また、この方式を採用することで、
- GUIによるログ参照性を維持できる
- ネットワークレベルでアクセス元を制限できる
というメリットを得られる一方、
- 許可IPアドレスの管理が必要になる
という運用上の負担は受け入れることとした。
今回重要だったのは、
最もセキュアな構成を選択することではなく、
セキュリティ・運用負荷・追加設計工数のバランスが最も良い構成を選択すること
であった。
最終的には、プロジェクト内およびお客様と認識を合わせた上で、本方式を採用することとした。
フローの振り返り
今回の課題解決プロセスを振り返ると、結果として採用した構成そのものよりも、そこに至るまでの進め方に価値があったと感じている。
今回の検討を通して改めて感じたのは、
「技術的に実現できること」と「採用すべきであること」は別である
ということだった。
技術課題に直面すると、つい
「実現できるか」
という観点に意識が向きがちである。
しかし実際のプロジェクトでは、
- 運用できるか
- 維持できるか
- 費用に見合うか
- 関係者が受け入れられるか
といった観点も同じくらい重要になる。
今回の検討では、まず実現可能性を整理することで、
「そもそも実現できない案はないか」
を先に明確化できた。
その結果、以降の検討では実現可否を気にすることなく、
どの方式が最適か
という比較検討に集中することができた。
また、比較検討を進める中で、最終的に重要な評価軸は以下の3点に整理された。
- セキュリティ
- 運用負荷
- 追加設計工数
振り返ると、この評価軸の整理が今回の意思決定の中で最も重要な作業だったと思う。
なぜなら、
- Private Endpoint はセキュリティが最も高い
- パブリックアクセスは運用性が最も高い
というように、各方式にはそれぞれ強みと弱みがあり、
「どの方式が優れているか」
という単純な比較はできなかったためである。
そのため、
何を重視して評価するのか
を整理しなければ意思決定自体ができなかった。
結果として今回は、
セキュリティ・運用負荷・追加設計工数のバランス
を重視し、パブリックアクセス（送信元制限）を選択した。
重要だったのは、
「正解を知っていたこと」
ではない。
- 選択肢を洗い出す
- 実現可能性を確認する
- 評価軸を定義する
- トレードオフを比較する
- 関係者と認識を合わせる
というプロセスを踏むことで、
なぜその結論に至ったのかを説明できる状態を作れたこと
に価値があったと考えている。
一方で改善点もある。
今回の検討では、評価軸の整理を比較検討と並行して実施していた。
最終的には問題なく意思決定できたものの、もっと早い段階で
- 何を重視するのか
- 何を比較するのか
を定義できていれば、検討をさらに効率的に進められた可能性がある。
今後、類似の技術課題に取り組む際は、
- 課題を整理する
- 実現可能性を確認する
- 評価軸を定義する
- トレードオフを比較する
- 関係者と認識を合わせて意思決定する
という流れを意識したい。
今回の題材は Azure Storage Account の設計だったが、この考え方はクラウド設計に限らず、多くの技術課題の解決に応用できると思う。