舞台裏: すべてのOCIをルール化する1つのUI DevOps (2024/04/23)

https://blogs.oracle.com/cloud-infrastructure/post/behind-the-scenes-one-ui-to-rule-all-oci-devops

投稿者： Robin Walsh | Principal Member of Technical Staff

クラウド企業でサービスを運営し、数回ブロックを回っている人は誰でも、その話を知っているでしょう: 金曜日の午後、電話が切れる激しい週末を楽しみにしています。オンコール・エンジニアであり、アラームしきい値に違反しています。今回は、Oracle Cloud Infrastructure(OCI)のオンコール・エンジニアで、内部操作用のJavaScript Webインタフェースを開発しました。いくつかの最初の調査の後、問題は私たちのサービスではなく、私たちの下流のサービスでいくつかのピンダウン問題があると判断しました。 言うようにハックニーとして、それはネットワークの問題のように見えました。そこで、ネットワークエンジニアを含む適切なサービスを紹介しました。

長年の短所として、トラブルシューティングをアゴナイズし、パケットがスタックをキャプチャしてダウンし、ベンダーを関与させた後、この問題は、グローバル・トランジット・プロバイダ(OCIではない)が所有するネットワーク・デバイス上の不正なポートが原因であることがわかりました。そこで、質問は、なぜJavaScriptエンジニアがインターネット・プロバイダのネットワーキング機器で循環冗長性チェック(CRC)エラーを検出するのかでした。この質問に対する回答は、フォローアップ・ブログの投稿で得られますが、まず、この内部UIとは何か、どのように機能するかについての履歴が必要です。

このブログ投稿では、OCI従業員がOracleクラウドをグローバル規模で運用できる単一ページ・アプリケーションであるDevOps Portal Experienceの内部について説明します。OCIエンジニアは、デプロイメント、アラーム、メトリック、ワークフロー、証明書などを毎日何十もの(そしてすぐに何百もの)のリージョンで定期的に管理します。もし、この作品を遂行するための世界クラスのツールがなかったら、われわれは一匹の猿の軍隊のようなものだ。幸いなことに、OCIの初期から、次の機能を使用して、リージョンのスコアを日常的に管理するためのUIツールの構築に優先順位を付けました。

• 設計による保護
• 楽(たの)しく使(つか)う。
• 安定

私たちは、私たちの決定が報われたと信じています、そして、この記事は、それが舞台裏でどのように起こったかを説明しています。

DevOpsポータル・エクスペリエンス: 先史(1.0)

初期の頃、他のOCIエンジニアと私は、当時まだ300人未満であったOCIエンジニアリング・コミュニティのためのクラス最高の内部運用ユーザー・インターフェイス(UI)の構築を担当していましたが、私たちが大きくなることはわかっていました。以前は、社内開発者が利用できるすべてのWebツールを使用していた、他の大規模なクラウド・プロバイダで作業していました。人々が決して見ることができない素晴らしいツールがたくさんありますが、改善の余地もたくさんあります!私たち二人は毎日解雇され、最も高性能なデザイン、最高の情報アーキテクチャ、そして私たちが想像できる最も使いやすいツールについて読む(そして発明する)ことになりました。

このWeb UIは、当初、サービスやリソースに関するOCIエンジニアのメトリックの表示、それらのメトリックに対するアラームの構成、およびコードのデプロイに使用されていました。当時は、テスト・リージョンとラボ・リージョン、最初の本番リージョンであるus-phoenix-1の2つのリージョンしかありませんでした。UIを単一ページ・アプリケーション(SPA)としてモデル化し、監視およびデプロイメント・サービスへのAJAXコールを行い、UIの要素を動的に更新することを決定しました。昔の学校のバックエンドエンジニアに回されたWeb技術の提唱者として、私はUNIXとコマンドラインの力を理解し、尊重し、時間のテストに立っている一握りのコマンドラインインターフェイス(CLI)ツールでよりよく解決される問題を解決するために、派手なWebツールを使用することに対する共通の抵抗を尊重します。

ただし、ブラウザが最良の選択である場合があります。同じリージョンまたはサービスに関連する何十もの時系列カーブを表示しますか。様々なマイクロサービス・アーキテクチャの10の同時デプロイメントを監視していますか。ログ・アラート・レベルおよび対応するメトリックを示すヒストグラムとともに、数百のホストからログをインターリーブしますか。これらすべてのケースで、データ密度の高いWeb UIが最適であり、このような場合は、DevOps Portal Experienceで解決するように設定しました。

初期の頃は、2人のエンジニアのみで、UIを操作する設計者はいませんでした。アトミック・デザインの原則を採用したと言いたいが、OCIの最も早い反復処理を実現するために、できるだけ早くスクリーンにペイントされたピクセルをできるだけ早く取り込もうと努力していた。それでも、パフォーマンスと正確性はどちらも非常に重要だったため、DevOps Portal Experienceのパフォーマンスと信頼性を維持するために、アプリケーション、定期的なパフォーマンスおよび回帰テストのユニットおよび統合テストを採用しました。

Reactは当時離陸したばかりだったが、フックはまだ何もなかったし、コンテキストAPIもなかったし、誰もグローバルな状態の問題を適切に解決していなかったし、AJAXリクエストを行うための複数の方法(明確な勝者なし)がまだあった。そのため、私たちは業界標準の慣行に従って、APIやライブラリが将来変更される可能性があることを知っていたシムやアダプタを記述し、一般的に開発プロセスを機敏に保つために最善を尽くしました。

OCIは、最初からセキュリティに真剣に取り組んでいます。あるリージョンのサービスは、単に別のリージョンのサービスを呼び出すことはできません。このため、興味深い制約が生じました。元のDevOps Portal Experienceエンジニアとして、確立されたセキュリティ・パターンに従いました。OCIは、最初はリージョンの分離に非常に厳格でした。設計上、ある地域が別の地域と話す方法はありませんでした。また、すべてに鍵を持つスーパーUIを作ることも許されませんでした。Oracle Cloudコンソールで使用されているものと同じプリンシパルを使用して、これを構築する必要がありました。Javascriptは、パブリックに使用可能なOCIサービスを呼び出します。唯一の違いは、DevOpsポータル・エクスペリエンスは、いくつかのOCI内部専用サービスと通信する必要があることです。

これらの制約の中で、各リージョンに1つのDevOpsポータル・エクスペリエンスUIを配置し、そのリージョンのサービスとローカルで対話するアーキテクチャが構築されました。OCIエンジニアがus-phoenix-1でメトリックを表示したり、デプロイメントを実行する場合は、そのWebインタフェースに移動します。今後のリージョン(us-ashburn-1)で何かをチェックアウトする場合は、別のアドレスにあるそのUIに移動し、重要なことに、クライアント証明書をブラウザに提示する別のユーザー・ログインが必要になります。安全だが退屈だ。

図1: リージョン分離が強力なOCIテネットであった場合のDevOpsポータル・エクスペリエンスの元のアーキテクチャ。

このアーキテクチャでわずか数か月後に、問題点に気づき始めました。DevOpsポータル・エクスペリエンスのログインには、すべてのOCI従業員に発行されたハードウェア2要素デバイスに格納されたユーザー名、パスワードおよびクライアント証明書が必要です。us-phoenix-1にデプロイし、再度ログインせずに次のリージョンにデプロイしたかったエンジニアから多くの苦情がありました。この問題は、eu-frankfurt-1を起動した後でさらに悪くなり、何千ものお客様のために数百ものレルムとリージョンに拡張されました。DevOpsポータル・エクスペリエンスのエンジニアは、変化が起きていると感じることができます。

より良いことができる(2.0)

私たちは素晴らしいものを作り始めましたが、目標に達しませんでした。オラクルの夢は、OCIの誰もができる限り効率的に(そして喜んで)仕事をすることができ、そしてそこから抜け出すことができるツールでした。この道具は邪魔になっていた。描画板に戻らなければならなかった。エンジニアに単一のアクセス・ポイントを与えるためには、異なるアーキテクチャを考え出す必要がありました。ホワイトボード・セッションを数回開催した後、お客様にとって適切なことは、インターネットに接続されたOCIリージョンに接続し、そこで稼働しているサービスに問い合わせることができる一元化されたWebアプリケーションを構築することであると判断しました。

私たちは、世界中の地域から多様なデータ(ログ、アラーム、メトリック、デプロイメント)を収集し、わかりやすい方法で顧客にそれらを表示できる単一のWeb UIを持つことを望んでいました。ユーザーが一度ログインして、グローバルOCIクラウドの運用を開始できることが約束されました。課題はより微妙でした: アプリはどのようにリクエストをルーティングしますか?このサービスを安全に保つにはどうすればよいでしょうか。OCIオペレーションに単一障害点を導入しましたか?

私たちはそれを正しく理解したかったので、主要な利害関係者と話し合いました。保証エンジニアは私達の設計が彼らの高い棒を渡したことを保障するのを助けました。この時点で、OCIとその一部のお客様には、リージョン境界を越えて話すための重要なユースケースがあり、DevOpsポータル・エクスペリエンスが一意でないことを確認しました。多くの点で、DevOpsポータル・エクスペリエンスはコンソールの内部バージョンのようにモデル化されています。ユーザーのブラウザで実行されるコードは、地域の境界を越えてAPIと対話します。

新しいクロスリージョン設計により、サービス・エンジニアは、自社のサービスをどのように公開する必要があるか、および認証と承認のために必要なものを理解しました。ユーザーは、すべてをできるだけ簡単かつシームレスに機能させることを望んでいます。そのため、これらの制約を使用して、DevOpsポータル・エクスペリエンスの次の反復を構築するように設定しました。結果として得られるツールは、OCIのグローバル・リージョン・フットプリントが数百に上るにつれ、私たちが誇るものであり、拡大し続けてきたものです。

最先端のツール

DevOps Portal Experienceユーザーの観点では、Web UIの新しい反復は古いUIとまったく同じように見えます。唯一の違いは、一度ログインするだけで、どのOCIリージョンでも何を表示する必要があるかを確認できることです。この点は、オーバーホールが終了するまでに、4つという番号が付けられました。バックグラウンドで、私たちは、スタック全体をセキュアで高速かつスケーラブルに保ちながら、ブラウザから正しいリージョンの正しいサービスにリクエストを透過的にプロキシする必要がありました。

図2: DevOpsポータル・エクスペリエンスのアーキテクチャは、リージョン境界を越えて話し合うことを許可された後です。

APIコール・ファンアウトを備えた1つの集中型UI。

新しい設計を導入した後、生産性の向上はすぐに明らかになりました。オペレータは、あるリージョンへのデプロイメントで作業しながら、次のリージョンのメトリックを同時にチェックして、同じUIでロールアウトを安全に続行できることを確認できます。また、アラームしきい値がリージョン間で類似していることを簡単に確認できます。開発経験はもっと良かった。DevOps Portal Experienceは単一ページ・アプリケーション(SPA)であるため、開発者はリージョン間でデータを格納、照合および比較して、以前は不可能だったインサイトをユーザーに提供できます。地域全体の主要業績評価指標(KPI)と対応する指標を示すリアルタイム・ダッシュボードが可能でした。ログ・エントリの比較およびリージョン間の異常の表示が可能でした。最も重要なことは、人間工学に基づいた効率的なエクスペリエンスがあればあるほど、OCIの従業員は業務を改善でき、OCIのパブリック顧客にとって、よりシームレスなエクスペリエンスを実現できることです。

この設計の主な欠点の1つは、すべての運用卵が1つのDevOpsポータル・エクスペリエンス・バスケットに入っていることです。元のエンジニアは、このトレードオフを軽く受け取らなかった。私たちは、次の例を含め、ツールが常に利用可能であることを確認するためにできるすべてのことを行います。

• DevOpsポータル・エクスペリエンスは、地理的に異なる2つのリージョンに存在し、それぞれに3つの可用性ドメインがあります。
• オラクルでは、これらのリージョン間の定期的なフェイルオーバーを実施して、確実に機能するようにしています。
• コードを段階的に展開し、回帰が世界中のユーザーに影響を与えないようにします。
• DevOpsポータル・エクスペリエンス・ツール自体には、他のOCIサービスへの依存性はできるだけ少なくなります。どのOCIサービスも、Identityのような基本的なサービスであっても、DevOps Portal Experienceを使用してサービスの問題をトラブルシューティングする必要があります。したがって、循環依存は許容できません。

DevOpsポータル・エクスペリエンスの構築にあたっては、使用できなかったインシデントや、両方のスタックが同時に使用できなかったインシデントはほとんど発生していません。今のところ、私たちの決断はうまくいっています!DevOpsポータル・エクスペリエンスを使用する社内OCI従業員のサンプルを非公式に調査したところ、導入事例のように、大規模なネットワーク停止中でも、高い稼働時間を当然のこととして受け止め、常にそれが利用可能であると期待していることがわかりました。

次の手順

信頼性とスケーラビリティを証明するDevOpsポータル・エクスペリエンスの数年の後、DevOpsポータル・エクスペリエンスのメンバー(わずか2つを超えて成長していた)は、OCI従業員が独自のツールを開発するためのプラットフォームを提供したいということに気付きました。また、1日に数時間しかないことに気付き、すべてのサービスにワールドクラスのUIを構築することはできませんでした。

そのため、コンソール・エンジニアとフェデレーテッド・プラグインの開発から手がかりを得ました。オラクルは引き続き堅実な基盤を提供していますが、OCIエンジニアは独自のUI専門知識を使用して、独自のペースで反復し、ユースケースに適した専門UIを構築できるようになりました。引き続き、複数のサービスが既製のUIコンポーネントを選択できるコンポーネント・ライブラリを維持しており、可能な限り一般化しようとしますが、特別なウィジェットが必要な場合もあります。

サービス間の依存関係をより明確にするUIを構築しています。DevOpsポータル・エクスペリエンスを真のオペレーショナル・エクセレンスを促進するツールにしたい場合は、すぐに何が起こっているのか、そしてなぜ起こっているのかをユーザーに示すことができるようにする必要があります。サービス依存関係グラフは、OCIオペレータが問題の根本原因を迅速に把握し、最終的にOCIのお客様を支援するのに役立ちます。

図3: DevOpsポータル・エクスペリエンスを使用して、サービス間の依存関係を表示し、インシデントの根本原因にすばやく到達する例。

オラクルは、OCI従業員のブラウザにJavaScriptを提供するサービスの能力を追跡するだけでなく、世界中のすべてのサービスに対するDevOps Portal Experienceの接続を間接的に監視するカナリア(モニタリング・システム)を倍増しています。このように監視する副作用は、グローバルネットワーキングイベントへの高いレベルの可視性があり、多くの場合、世界のどこかでファイバーのスパンがいつカットされるかを知る最初のものであるということです。このコンセプトについては、今後のブログ記事で詳しく説明します。これは、OCIで何かが起こっている可能性があることをオペレータに知らせる最も初期の兆候の1つです。

今後もUIの動向を注視し、安定性とユーザビリティに注力していきます。素晴らしいCSSとJavaScriptライブラリがそこにあります。しかし、UIとUXの世界のトレンドがあまりにも多くのフリルを提供し、十分なユーティリティを提供していない場合、私たちはそれを止めることができます。

まとめ

OCIはエンジニアリング組織として成長し続けており、生産および計画されているOracle Cloudリージョンの数が100リージョンを超えると、DevOps Portal Experienceは依然として強力で、適切にスケーリングされており、数千人の日常ユーザーが確認できるため、最も信頼性が高く、パフォーマンスの高いOCIツールの1つとして時間のテストが行われています。

• 私たちは、最初は限られた知識とツールで作業し、私たちの期待を調整して、私たちのデザインを繰り返しました。
• 私達はあらゆるターンで顧客に正しいことをしようと試みた。
• 信頼性が第一の目標であり、パフォーマンスはそれほど遅れず、可能な限り最適化し続けています。
• Oracle Cloud Infrastructureエンジニアリング・コミュニティと引き続き関わり、DevOpsポータル・エクスペリエンスをさらに改善するための意見を受け入れています。

前述したように、私たちはこの複雑で絶えず変化する獣医を監視する必要があります!最終的に、私たちは、世界的なインターネットトラフィックの傾向を示す監視システムである、私たち自身のカナリアを思いつくようになりました。それが次回のお話です!

このブログ・シリーズでは、優れたクラウド製品を提供するために、OCIエンジニアが直面している新しいプロジェクト、課題、問題解決について説明します。OCIエンジニアリング・シリーズでは、Oracle Cloud Infrastructureで働く優秀なエンジニアを擁するOCIエンジニアリング・ディープ・ダイブを舞台裏でご紹介します。

詳細は、次のリソースを参照してください。

• More on UI architecture with Behind the Scenes: Scaling UI for hundreds of services
• and Behind the Scenes: Building OCI's next-generation UX with atomic design