エッジは複雑だ。この基本的なステートメントを理解するという、身震いするような巨大さと衝撃的な現実を乗り越えれば、目の前の課題を中心にフレームワーク、アーキテクチャ、そしてサービスを構築し始めることができるかもしれない。Linux Foundationが昨年発表した「State Of The Edge」レポートは、簡潔にこう述べている。「エッジは、そのあらゆる複雑さゆえに、それ自体が急速に変化し、強力で、要求の厳しい産業となっている。」
Red Hatは、ITスタックをこの領域にまたがって移行するすべての企業が今後担うであろう、複雑なエッジ管理の役割を冷静に認識しているようだ。同社は、エッジコンピューティングを「オープンハイブリッドクラウドを地球上のあらゆるデータソースとエンドユーザーにまで拡張する」機会と捉えているという。
Red Hat は現在、国際宇宙ステーションと近所の薬局にあるものと同じくらい多様なエッジ エンドポイントを例に挙げ、特定のエッジ ワークロードの課題に対処する自社のプラットフォームの部分を明確にし、検証することを目指しています。
最先端技術の最前線
エッジとクラウドは密接に結びついていますが、私たちの使命は、データセンターの外部、エッジの最先端でコンピューティングの決定を可能にすることです。
「組織は、スマートシティのインフラ、患者のモニタリング、ゲームなど、あらゆる業界のさまざまなユースケースをサポートするために、パフォーマンス、コスト、効率を最適化する方法としてエッジコンピューティングに注目しています」と、Red Hat のシニアソリューションアーキテクト、エリカ・ランギ氏は述べています。
参照: 熱意を抑えないで: エッジコンピューティングのトレンドと課題 (TechRepublic)
エッジコンピューティングの概念は、明らかに、情報へのアクセス場所と処理方法に対する新たな視点を提示しており、より高速で信頼性が高く安全なアプリケーションを構築するためのものです。多くのソフトウェアアプリケーション開発者は、ネットワークにおける広義の意味で「分散化」の概念に精通しているかもしれませんが、エッジ開発者は2つの重要な考慮事項に着目すべきだとランギ氏はアドバイスしています。
「まずはデータの一貫性です」とランギ氏は述べた。「エッジデータが分散しているほど、より高い一貫性が求められます。複数のユーザーが同時に同じデータにアクセスしたり変更したりする場合、すべてが同期されている必要があります。エッジ開発者は、エッジネイティブなデータ転送、データ集約、そして統合エッジアプリケーションサービスを構築するためのデータ一貫性を支える強力な基盤として、メッセージング機能とデータストリーミング機能について考える必要があります。」
Edgeのスパース要件
エッジ環境の複雑さを強調する必要がある理由は、これが異なるコンピューティングであるという事実に起因しています。つまり、顧客が「要件仕様」ドキュメントやユーザー インターフェイスの設定を提供することはありません。このレベルでは、よりきめ細かいマシン レベルのテクノロジ構造を扱っています。
エッジ開発者にとって 2 番目に重要な考慮事項は、セキュリティとガバナンスに対処することです。
「広大なデータ領域を運用するということは、攻撃対象領域がデータセンターの外にまで広がり、保存データや移動中のデータも影響を受けることを意味します」とランギ氏は説明します。「エッジ開発者は、このようなシナリオにおいてデータ保護を強化するために暗号化技術を導入できます。数千ものセンサーやデバイスが接続されるネットワークの複雑さが増す中で、エッジ開発者はセキュリティを確保するために、自動化、一貫性、拡張性、ポリシードリブンのネットワーク構成の実装を検討する必要があります。」
最後に、彼女は、不変のオペレーティング システムを選択することで、開発者は攻撃対象領域を縮小し、組織がセキュリティの脅威に効率的に対処できるようにすることができると述べています。
しかし、開発者にとって、従来のソフトウェア開発からエッジインフラストラクチャへの移行を真に変えるものは、ターゲットデバイスの多様性とその整合性です。これは、Red Hatの開発者ストラテジストであるMarkus Eisele氏の見解です。
「開発者は通常、フレームワークについて考え、アーキテクトは API とすべてをどのように接続するかについて考えますが、エッジにコンピューティング ユニットがある分散システムでは、異なるアプローチが必要です」とアイゼル氏は述べています。
必要なのは、包括的かつ安全なサプライチェーンです。その第一歩は、統合開発環境（アイゼル氏とチームは、Kubernetesとコンテナを活用したゼロコンフィギュレーション開発環境であるRed Hat OpenShift Dev Spacesを挙げています）です。これらの環境は、安全なインフラストラクチャ上でホストされ、開発者が様々なターゲットプラットフォームやコンピューティングユニット向けのバイナリを構築できるよう支援します。
ベース上のバイナリ
「理想的には、ここでの自動化はコンパイルの成功をはるかに超え、検証済みのベースイメージ上にテスト済み・署名済みのバイナリを作成する段階まで進むべきです」とアイゼル氏は述べた。「こうしたシナリオはガバナンスの観点から非常に困難になる可能性がありますが、開発者にとって繰り返し実行可能で、内部ループと外部ループへの影響を最小限に抑える必要があります。一見すると大きな変化は見られませんが、エラーの余地はさらに少なくなります。特に、生成された成果物のセキュリティや、開発者の生産性を維持しながらすべてがどのように連携するかを考えると、なおさらです。」
アイゼル氏が言及した内側のループと外側のループは、ここでの複雑さを象徴しています。内側のループは、コードを迅速にテストおよび変更できる単一の開発ワークフローです。外側のループは、コードがバージョン管理システム、または本番環境への展開に近いソフトウェアパイプラインの一部にコミットされるポイントです。さらに明確にするために、上記のソフトウェア成果物の概念は、開発者がコードを構築するために使用または作成する可能性のあるあらゆる要素を指すことを思い出してください。つまり、これにはドキュメントや注釈メモ、データモデル、データベース、その他の形式の参考資料、そしてソースコード自体が含まれます。
参照: 採用キット: バックエンド開発者 (TechRepublic Premium)
確かなことは、何十年も前から導入されているデータ センターやクラウドとは異なり、エッジ アーキテクチャは依然として指数関数的な速度で進化を続けているということです。
目的意識をかわす
「アーキテクトと開発者が今日行う設計上の決定は、将来の機能に永続的な影響を与えます」と、Red Hatのエッジコンピューティング担当テクニカルエバンジェリスト、イシュ・ヴァーマ氏は述べています。「エッジの要件は業界ごとに異なりますが、設計上の決定がエッジだけに特化したものではないことが重要です。そうしないと、組織の将来の俊敏性と拡張性が制限される可能性があります。」
エッジ中心のRed Hatエンジニアたちは、クラウド、オンプレミス、エッジなど、あらゆるインフラストラクチャで、また業界を問わず利用可能なソリューションを構築することが、より良いアプローチであると主張しています。コンテナ、Kubernetes、軽量アプリケーションサービスといった、将来を見据えた柔軟性の確立に役立つテクノロジーを選択するというコンセンサスが固まりつつあるようです。
「エッジアプリケーションには、様々なユースケースに共通するモジュール性、分離性、そして不変性といった要素があり、コンテナはまさにこうした要件に合致するのです」とVerma氏は語る。「アプリケーションは、それぞれ独自のリソース特性を持つ、様々なエッジ層にデプロイする必要があります。マイクロサービスと組み合わせることで、機能のインスタンスを表すコンテナは、基盤となるリソースや状況に応じてスケールアップまたはスケールダウンすることができ、エッジにおける顧客のニーズを満たすことができます。」
エッジ、しかし大規模
これらすべての課題が私たちの前に立ちはだかっています。慌てる必要はないというメッセージはありますが、エッジ環境向けに安全にスケーリング可能なソフトウェア・アプリケーション・エンジニアリングを構築しなければならない場合、課題はさらに困難になります。大規模なエッジには、さまざまな場所に展開された数千ものエッジ・エンドポイントを管理するという課題が伴います。
「相互運用性は大規模なエッジにとって重要です。インフラストラクチャやクラウド プロバイダーが要求するフレームワークに合わせてリファクタリングすることなく、同じアプリケーションをどこでも実行できなければならないからです」と、Red Hat の EMEA エッジ市場開拓スペシャリストであるサリム・コドリ氏は述べています。
Khodri氏のコメントは、開発者がアプリケーションの開発、展開、保守方法を変更することなく、エッジコンピューティングのメリットを活用できる方法を知りたいと考えているという点に合致しています。つまり、既存のスキルを活用してエッジでのプログラミング体験を可能な限り一貫性のあるものにすることで、エッジコンピューティングの導入を加速し、分散展開の複雑さに対処する方法を理解したいと考えているのです。
「CI/CDパイプライン統合、オープンAPI、Kubernetesネイティブツールといった一貫性のあるツールと最新のアプリケーション開発のベストプラクティスは、これらの課題の解決に役立ちます」とKhodri氏は説明します。「これは、マルチベンダー環境におけるエッジアプリケーションの移植性と相互運用性、そして分散エッジにおけるアプリケーションライフサイクル管理プロセスとツールを提供するためです。」
ここで重要なアドバイスを片手で列挙するのは難しいでしょう。2つ挙げるのは困難で、多少の労力も必要になるかもしれません。キーワードはおそらくオープンシステム、コンテナとマイクロサービス、構成、自動化、そしてもちろんデータでしょう。
分散型エッジはデータセンター DNA から始まり、クラウドネイティブ IT スタック バックボーンとの密接な関係を一貫して維持しますが、これは本質的に切断された関係の組み合わせです。
