ライター：井上 勝晴 2002年にネットワンシステムズ入社後、応用技術部にてVoIP/Mobile/Telemetry等の通信キャリア様向けの技術を担当
はじめに
前回のブログ に引き続きまして、ONUG（ ONUGについての解説はこちらの過去ブログへ ）での議論を下記のポイントでまとめ、4つの連載記事でご紹介していきます。本ブログではONUGが提唱するElastic Infrastructureの実態の解説と、その他の注目ワーキング・グループの活動を紹介いたします。
Elastic Infrastructureへの道筋 こちらのブログ でもご紹介しておりますが、ONUG Spring 2021にて Elastic Infrastructure のアーキテクチャ検討が一段落したこともあり、本イベント：ONUG Fall 2021ではエンタープライズITのあるべき姿として定義される Elastic Infrastructure に向かう道筋 （Journey Map） について、WGより説明がありました。下図にあるように、 Elastic Infrastructure にはElasticity（柔軟性）に応じたレベルが定義されており、そのレベルに応じてビジネス上で授受出来るメリットが変わってくる、と言うものです。ポイントは、あるべき Elasticity（柔軟性） の粒度にNetworkとSecurityの二大IT管理要素が明確にリストされている点、そしてこの二大管理要素が統合されて初めてLevel 4のPolicy Managementへ移行されるべきであり、ひいては最終段階とされるLevel 5のオンデマンド・コントロールが達成される、と明確に定義がなされたことでしょう。
参考：ONUG Fall 2021より- https://onug.net/events/elastic-infrastructure/ >
以前のブログでもお伝えしていますが、ONUGのElastic Infrastructureにはインフラを各Opsのサイクルと接続することで「ビジネス≒アプリケーション」と「インフラ」の連携を向上しようという考え方が根底 にあります。本イベントで更に明確に、NetOpsとSecOpsの統合がElastic Infrastructureへ向かう過程で不可欠である点が示されました。
何処にどんなElasticity（柔軟性）を持たせるのか？ エンタープライズITの何処にどのようなElasticity（柔軟性） を持たせるべきか？、の議論も活発でした。これは企業文化や利用するアプリケーションに大きく依存するものではありますが、大きく一般化すると下図にあるように、Endpoint・Network Service Edge・Middle Mile Optimization・Cloud Networksの四箇所の分類で議論がなされていました。下図にある緑のBoxが、各Pointで持つべきElasticity（柔軟性） の例となります。
<参考：ONUG Fall 2021より - https://onug.net/events/elastic-infrastructure/ >
また、本イベントでとりわけ特徴的であったのが、Edgeの利活用に 参加企業の多くが 注目している点でした。「COVID19によりWorkforceが分散化された今、COVID19前のようなワークロードがPublic Cloudに代表されるセンター（中央）に位置しているのは、遅延やSecurityの観点で適切では無い。むしろ ワークロード を実行する側に近い位置での実装が必要となる」、このように考える企業が多く存在し、実際、この考えを加速させるべく、Edgeリソース上でCICDパイプラインが適用出来るように開発者に新たな権限を付与する業務プロセスの変更を実施した、このような企業の発表もありました。また参加する配送業者からは、「物品毎の仕分けに要する時間がオペレーションコストに直結するため、ロボットやドローンの活用を進めているが、連動するシステムとの間の遅延が大きな課題であった。しかしEdgeを活用する事で仕分け業務を40ミリ秒短縮する事ができた。この40ミリ秒は大きな成果だった。」このような声もセッションでは聞く事が出来ました。
Cloud Sprawl (クラウドの無秩序)を防ぐ方策とは Cloud Sprawlを防ぐ方策として前ブログでお伝えした「コスト管理」以外の検討が、幾つかのWGセッション・Keynoteにて語られていました。企業のIT担当者がクラウドに感じる主なペインポイント、①ワークロードの実態が把握しにくい、②クラウド事業者毎に用語やメッセージバラバラ、この2点について訴求する内容でありました。
①ワークロードの実態が把握しにくい ==> Elastic Infrastructureのプロパティ Elastic Infrastructure を理解する上で有用な「プロパティ」についても、WGより説明がありました。エンタープライズのワークロードがマルチ・クラウドに移行されると、企業のIT管理者がコントロール出来ない要素が加わり、それもあって、その実体が不明瞭になることがあります。そして、このような不明瞭さは「Cloud Sprawl (クラウドの無秩序) 」の要因となります。そこで、クラウドに移行されたワークロードの実体を正確に捉えられるよう、下図にある「Elastic Infrastructure Properties」がWGにて議論されています。未だ柔らかい検討段階のようでありますが、クラウドへのアクセスを規定するCloud Access、アプリその物となるData Plane、その双方をOverlayするOperationとSecurity、これら全体を統合するControl Plane、これら5つの要素での整理が進められています。またコンポーネント図には未だ組み込まれていませんが、管理者の意図（Intend）をベースにDeclarative （ 宣言的）に全体を指揮する機能要件も検討が進められています。
<参考：ONUG Fall 2021より - https://onug.net/events/elastic-infrastructure/>
②クラウド事業者毎に用語やメッセージバラバラ ==> CSNF (Cloud Security Notification Framework)による標準化 「 Cloud Sprawl (クラウドの無秩序) 」を引き起こす要素として、 各クラウド上で用語・設定・APIが其々異な り標準化されていない点も大きな原因であるとONUGは考えています。そしてこの課題をSecurity Alertの観点で切り出したのがCSNF（Cloud Security Notification Framework）であり、具体的には主要クラウド事業者でのSecurity Alertの標準化を実現しようとする ONUG Collaborative WGの活動となります。（2021年11月時点でAzure、IBM、Google、Oracleが参加）
今回、Gitに公開されているテストコードを用いたデモンストレーション もあり、①各クラウド事業者から提供されるRawデータには変更を加えず、②Rawデータの意味をNIST等の一般的な解釈へと変換を可能するCanonical Dictionary （標準辞書）を作成し、③メタデータを使用してRawデータをCanonical Dictionary（標準辞書） にマッピングし、④SIEM等のセキュリティコンポーネントがそれを参照して運用に役立てる、この4点のコンセプトデモがなされていました。
<参考：ONUG Fall 2021より- https://onug.net/events/a-new-model-for-multi-cloud-security-notification-the-onug-csnf-decorator-demonstration/ >
まとめ
本ブログでは ONUGが提唱する 「 Elastic Infrastructure 」とCloud Sprawlを防ぐ方策 と しても期待される「CSNF（Cloud Security Notification Framework）」の実態を、其々ご紹介しました。 次回のブログでは、この先進的なアーキテクチャを実現する、弊社ネットワンシステムズのONUG Community活動をご紹介します。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
<>
