クラウド障害の発生は非常に大きなストレスとなります。問題の解決まですべてが止まってしまい、クラウドプラットフォームのインターフェイスからリソースの設定ミスを拾い出すのには多大な時間と労力がかかります。
障害の診断にはクラウドを文書化した記録が役立ちますが、内容が最新版でなければ無意味です。内容が古くなった図であれば、ない方がましなこともあるでしょう。
最終的には、障害の可能性に備えて常日頃から準備しておくことが重要です。準備がしっかりできていれば、問題を切り分け、スピーディに復旧できる可能性が高まります。
この記事を読むのに必要な時間 : 2 分
クラウドのビジュアル化には、Lucidscale を試してみましょう。素早く、簡単に使えて、完全に無料です。
Lucidscale を活用してクラウド障害の原因を究明する方法
-
Data Hub にアーキテクチャをインポート
Lucidscale で左側のパネルに移動して [データをインポート] を選択すると、クラウドプロバイダーのメタデータが取り込まれ、現在の状態を正確に把握した図が生成されます。Lucidscale は AWS、Azure、GCP と連携します。詳しい手順はヘルプセンターのデータのインポートに関する記事を参照してください。
インポートしたデータからモデルを自動生成します。フィルターの適用、ビューのカスタマイズ、接続されたリソースの表示などが可能になります。
-
カスタムビューのトラブルシューティング
既存のビューを使用するかカスタムビューを作成して、フィルター、線や条件付き書式のルールを追加し、クラウドインフラストラクチャで問題を確認したい部分を絞り込みます。
フィルターを使用して、障害の原因と思われる部分を重点的に確認したり、問題がないと確認できたリソースを除外して図を整理します。線の表示と非表示を切り替え、特定のリソースが適切に接続されており、接続に欠けがないことを確認します。条件付き書式ルールを使えば、メタデータの一部を対象に設定が不適切なリソースをすばやく簡単に探せます。
-
主要なデータにアクセス
Lucidscale のデータパネルから主要なデータにアクセスでき、モデルとクライアントのクラウドプロバイダーのコンソールの間を行き来する必要はありません。
-
将来の障害に備える
クラウドアーキテクチャモデルを可能な限り正確な状態に保てるよう、Lucidscale Data Hub 内のデータソースは常に更新するようにしましょう。こうすることで、障害が発生した場合でも、インシデント対応に役立てることができます。
Lucidscale を活用した障害発生時のトラブルシューティングの例
Lucidscale は、障害の原因究明に大いに役立ちます。例えば、ある大手スポーツアパレル企業では、Lucidscale でクラウド文書を最新の状態に保ち、障害発生の可能性に備えています。
Lucidscale 導入前、同社では、現状を表すクラウド図がなかったために障害が長引く事例が発生しました。図の中には、半年も更新されていないものもありました。こうなると、インシデント対応の担当者が現状を把握するために多大な時間がかかってしまいます。
現在、同社では、Lucidscale を使って正確なクラウド図を 生成し、インシデントの特定や現在のインフラストラクチャの状況をチームに伝えるために利用しています。
別の例として、あるトラック運送会社での Lucidscale 活用方法も見てみましょう。Lucidscale を採用する以前に同社では3週間に及ぶ障害を経験しました。これは、状況を把握できる人がチームの中に一人しかいなかったことが原因で、問題を特定するために、コードのすべてをリバースエンジニアリングする結果となりました。
当社のチームが同社に Lucidscale でクラウド図を自動生成する方法を紹介した後で、トラブルシューティングを担当した方から、(これがあれば) 障害の問題特定が数週間ではなく数分で完了し、ダウンタイムも短くて済んだはずだというコメントをいただきました。
クラウドを表すビジュアルが手元にあれば、クラウドプラットフォームで数百行に及ぶテキストを読み込む必要もなくなり、クラウド環境の問題特定がスムーズに変わります。最新のクラウドモデルを生成できる Lucidscale を活用すれば、フィルタリング、線や条件付き書式設定などの機能で障害の原因を迅速に絞り込め、インシデント対応にかかる時間を節約し、対応プロセスを改善することができます。