火災が起きたのは9月26日。朝鮮日報などが14日に報じたところによれば、無停電電源装置のバッテリー交換中に火災が発生し、リチウムイオンバッテリー384個が燃えた他、サーバが全焼し、政府の709システムがまひした。
この火災により、74省庁の職員12万5000人（政府職員の約17％）が利用していたオンラインストレージ「G-Drive」に関する機器が焼失し、バックアップもなかったため8年分の業務資料に当たる858TBのデータが利用できなくなったことも報じられている。まひしたシステムのうち306システムは14日時点で復旧済みという。
⇧ よく分からんのだが、「リチウムイオン」を代替できる技術は無いんかね？
「リチウムイオン」は可燃性が高いって話なので、発火してしまうと消火が困難だと思うので、そのあたりの課題が解決できないと同じ被害が再現されてしまうリスクを抱えた状態になってしまう気がしますしな。
復旧割合が、
ということで、1か月経っていないが43%近く復旧が済んでいるのは、素晴らしい。
復旧作業に従事されておられる方の頑張りには、ただただ頭が下がる思いですな。
ライフサイクル管理ポリシーは、Azure Blob Storageのデータ管理の機能の1つ
相変わらず、カオスな「Microsoft」の公式のドキュメントによると、
⇧「Azure Blob Storage」のドキュメントに整理されていることから、「Azure Blob Storage」の「データ管理」の「機能」の内の1つということになるようだ。
ややこしいのが、「Azure Blob Storage」は、
Blob Storage のリソース
Blob Storage には、3 種類のリソースがあります。
- ストレージ アカウント
- ストレージ アカウント内のコンテナー
- コンテナー内の BLOB
https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-introduction
次の図に、これらのリソースの関係を示します。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-introduction
⇧ 上記のような構造になっているので、どのリソースに対しての「機能」なのかを把握する必要があるのだが、例の如く「Microsoft」の公式のドキュメントは「ファインダビリティ（Findability）」の欠片も無いので、「サービス」の「利用者（ユーザー）」に「不毛」な「検索」を強いるという...
話を「ライフサイクル管理ポリシー」に戻すと、
Azure Blob Storage ライフサイクル管理の概要
Azure Blob Storage を使用すると、データ ボリュームの増加や使用パターンの進化に伴い、組織はデータ ストレージのニーズを効率的に管理およびスケーリングできます。 BLOB ライフサイクル管理を使用することで、お客様はルールベースのポリシーを実装することで、データをよりクールな層に自動的に移行したり、不要になったときに期限切れになったりすることで、コストを事前に最適化できます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/lifecycle-management-overview
このシームレスな自動化により、データは常に最もコスト効率の高い方法で格納され、簡単なアクセスと堅牢なデータ管理を維持しながら、予算効率を最大化できます。 BLOB ライフサイクル管理を使用すると、組織は、コストが最適化され、実際の使用状況に従ってデータが管理されることを知りながら、ストレージ環境を自信を持ってスケーリングできます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/lifecycle-management-overview
ライフサイクル管理ポリシーを使用すると、以下を行えます。
-
コストを最適化するために、BLOB の現在のバージョン、BLOB の以前のバージョン、または BLOB スナップショットが一定期間アクセスまたは変更されない場合に、これらのオブジェクトをよりクールなストレージ層に移行します。
-
BLOB がアクセスされたときに BLOB をクールからホットに直ちに戻します。
-
ライフサイクルの最後に、BLOB の現在のバージョン、BLOB の以前のバージョン、BLOB スナップショットを削除します。
-
ストレージ アカウント全体または選択したコンテナーに、あるいは名前のプレフィックスや BLOB インデックス タグをフィルターとして使用して BLOB のサブセットにルールを適用します。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/lifecycle-management-overview
⇧ とあり、「用語」の説明が無いのよな...
そもそも、唐突に出てくる「BLOB ライフサイクル管理」の定義を説明しろという話であって、不親切極まりないというか、対象の読者が「経営層」の場合、ブチ切れられると思うんだが...
つまり、「利用者（ユーザー）」を「顧客」とも思っていないような傲岸不遜な思想が透けて見えてしまうことが、誠に遺憾である...
ちなみに、
⇧ 上記にあるように、複数の「ストレージアカウント」を利用しているような場合は、「Azure Storage Actions」という「機能」を使った方が良いかもしれないケースもあるようだ。
「Azure Blob Storage」の「データ管理」の「機能」の全量が分かり辛過ぎるんだが...
何故、1か所に情報を集約しないのか...
Azure Blob Storageのライフサイクル管理ポリシーの個数の制約はないと考えれば良いのだろうか
一応、公式のドキュメントで「既知の問題と制約事項」が列挙されているのだが、
⇧ 上記の内容を見ても、「ライフサイクル管理ポリシー」の個数については、特に「制約」が設けられていない。
ドキュメントが散逸しているのだが、
⇧ こちらでも
「ライフサイクル管理ポリシー」の個数についての「制約」の記載が無いのよね。
海外勢の質問の回答によると、
Important considerations:
Lifecycle policies operate based on rules that use a set number of days (such as daysAfterModificationGreaterThan) to manage transitions. Since there is a limit of 100 rules per storage account, it's not practical to create a separate rule for each blob or for every unique transition schedule.
⇧ 上記で、1つの「ストレージアカウント」は最大で「100」個が上限という「制約」があるようなのだが、ドキュメントに見当たらなかったんだが...
もし、
⇧ 上記のことを言っているのだとしたら、
『Since there is a limit of 100 rules per storage account』
は読み取れないので、ドキュメントを修正して欲しい...
少なくとも、ドキュメントに、
- 1つのストレージアカウントには、1つのライフサイクル管理ポリシーか作れない
- 1つのライフサイクル管理ポリシーは、100個までしかルールを持てない
- 1つのストレージアカウントは、100個までしかルールを持てない
⇧ というような情報を記載してくれないと、推測の域の話にしかならないのでね...
頼むから「Microsoft」は、ドキュメントの内容について、情報を集約するようにして欲しい...
何を気にしているかというと、1つの「ストレージアカウント」に10000個の「コンテナ」があるとして、10000個の「ライフサイクル管理ポリシー」を紐付けできるのかということ。
まぁ、
となることもあると思うので、悩ましい問題ではあるのだが...
コストの問題が許されるのなら、
とするのが良さそうな気はするが、「ストレージアカウント」を複数利用しているような「ソフトウェア」の場合は、
となることもあると。
「Microsoft Azure」の「テナント」毎に分離できれば良いのかもしれないが、コストが割高になり過ぎると思いますしな...
「マルチテナント」の「構成」の「ソフトウェア」の場合、「お客様」毎に「コンテナ」を用意することになると思うのだが（「お客様」毎に「ストレージアカウント」を用意するという手もあるが）、「ライフサイクル管理ポリシー」も「お客様」毎に用意しておいた方が「影響範囲」を閉じれて良い気はする。
10000個もとなると管理が大変となるのだが、
⇧ 上記にあるようにコマンドが用意されている。
コマンド側を確認してみたのだが、
⇧ 上記でも「ライフサイクル管理ポリシー」の個数についての「制約」は見当たらない。
なので、「ライフサイクル管理ポリシー」の個数についての「制約」が無いのであれば、
- ライフサイクル管理ポリシーのテンプレートのJSONファイルを用意しておく。
- テンプレートのJSONファイルを元に顧客毎の設定をオーバーライドしたJSONファイルを生成する。
- コンテナ毎（お客様毎）のライフサイクル管理ポリシーをコマンドで生成する。
といったようなプログラミングを組むことができるはずなので、「デプロイ」ないしは「デリバリー」時に、お客様を一意に識別できる情報を渡してスクリプトを実行することで、お客様毎に環境を分離するといったことができそうではある。
なのだが、「裏仕様」で、
『「ライフサイクル管理ポリシー」の個数の制約はあります。』
とかありそうなのが怖いのよな...
仮に「ライフサイクル管理ポリシー」が1つしか作れないとすると、お客様毎の「ルール」を追加する度に、毎回「ライフサイクル管理ポリシー」を更新しないといけなくなるので、他の「お客様」の環境に影響が出る懸念が出てくる...
それに、管理するお客様の数が多い場合に、「ストレージアカウント」を追加する必要が出てくる可能性があり、1つの「ストレージアカウント」で「ペタバイト (petabyte,記号:PB)」のデータを扱えるのが無駄になるのよね...
「Azure Blob Storage」は設計が破綻していらっしゃることになるのだが、「Microsoft Azure」は他サービスでも破綻している部分が多いのよな...
と言うのも、
⇧ 上記サイト様にありますように、「Microsoft Azure」による被害の事例が多いですからな...
公式のドキュメントは、一次情報になるので、正確な情報を載せて欲しいのよね...
まぁ、「Microsoft Azure」に限らず「クラウドサービスプロバイダー」のドキュメントが酷い状況ではあるので改善して欲しいお気持ち...
なのだが、特に「Microsoft」は突出して酷い状態な気がするのよ...
そもそもとして、IT系全般のドキュメントにおいて、情報が散逸していて整理されていない酷い状態のものがデフォルトになってしまっている気はするのだが...
「利用者（ユーザー）」が不利益を被る状態を良しとする悪しき習慣は無くして欲しいのよな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
