エッジコンピュータを活用した、新たなクラウドシフト手法の可能性：分散クラウドのアーキテクチャと開発・運用体制の考え方

クラウド移行における手法の一つである「リフトアンドシフト」。取り組みたい企業が多い一方で、その過程には多くの課題があるのが現実だ。これらの課題を解決する策として、エッジコンピュータの活用が注目を集めている。

[工藤雄大，株式会社日立ソリューションズ]

　企業にとってクラウドは当たり前の存在になりつつある。一言でクラウドと言ってもパブリッククラウドやプライベートクラウド、ハイブリッドクラウド、デディケイテッドクラウド、マルチクラウドなどさまざまで、国内外問わずクラウドシフトの事例や方法論も存在する。一方、パブリッククラウドへのクラウドシフトには依然として課題もある。

　連載第1回となる本稿は、分散クラウドの技術要素であるエッジコンピュータが既存のクラウドシフト手法の課題をいかに解決するかを解説し、第2回では移行後のシステムにエッジコンピュータを取り入れることで、性能やセキュリティ、コストといった課題にどのような効果があるのかを紹介する。そして最終回の第3回で、分散クラウド上で開発・運用を円滑に進めるための組織構成を解説する。

この連載について

　本連載は、企業が抱えているクラウドシフトに関する課題を解決するために、エッジコンピュータを活用した新たな手法がなぜ効果的なのかを解説します。

筆者紹介：株式会社日立ソリューションズ　工藤雄大

技術革新本部 生産技術部 Cloud CoE 技師

インフラ系新技術、新製品の評価及びソリューション開発に15年以上従事。特技は製品・技術を外から(not Source)挙動解析。近年のテーマはエッジコンピュータ、分散クラウド関連技術。インフラ系技術コミュニティでも活動。

エッジコンピュータを活用した、新たなクラウドシフト手法の可能性

　パブリッククラウドへのクラウドシフトにおいて、多くの企業は以下のような課題を抱えている。

1. 既存のクラウドシフト手法が適用しづらい

　クラウドシフトの手法として有名なものに「リフトアンドシフト」がある。本連載ではリフトとシフトは以下の順に実施するものと定義する。

• リフト：オンプレミスの既存のワークロード（アプリ、サーバなど）をパブリッククラウド上にストレートに移行する
• シフト：パブリッククラウドに最適になるように作り替える

　このリフトアンドシフトを実行しようとしても、何らかの理由でリフトできず、オンプレミスシステムとして塩漬けになるパターンも多い。

2. パブリッククラウド移行後の転送量増加

　パブリッククラウドへ移行した後に課題が発生するケースもある。クライアント数やデータ量が増加した場合は、データ転送料金の高騰も考えられる。スマートフォン向けのコンテンツ配信などによって生じるアウトバウンド通信コストなども課題だ。

既存のクラウドシフト手法が適用しづらい理由

　「既存のクラウドシフトの手法が適用しづらい」という意見も多いが、その理由はどこにあるのだろうか。筆者は「コスト」「ロケーション」「技術難易度」に問題があると捉えている。

既存のクラウドシフトのメリット、デメリット（筆者作成）

1. コスト

　システム規模が小さい場合の運用コストは、クラウド移行完了後に下がる可能性が高い。一方、一時的なコストとしては「移行前の現状分析コスト」「移行コスト」がかかり、さらにはクラウドに熟知したエンジニアを育成する「人材育成コスト」も存在する。また、先述のコンテンツ配信プラットフォームなどの特定構成では、想定外のコストが発生する可能性もある。

2. ロケーション

　データをパブリッククラウドに保存する場合、ロケーションの観点で機密情報保護やデータ転送遅延といった課題がある。

　機密情報に関しては、以下の図で示すように「設計図や個人情報、他社情報などをパブリッククラウドに保存してよいのか」と不安に思う企業も多い。これについてはデディケイテッドクラウドやISMAP（Information system Security Management and Assessment Program）に登録されたクラウドサービスの採用などで対応できる。

システムのロケーション観点での課題（筆者作成）

　データ転送遅延に関して、オンプレミスとクラウドの連携時に発生する問題もある。例えば工場などで用いられることの多いOT機器はミリ秒やマイクロ秒単位で稼働しており、それを管理するシステムの応答速度要件も厳しい。この管理システムだけをパブリッククラウドにクラウドシフトした場合、OT機器と管理システムはネットワーク上で遠くなる。その結果、上図が示すように応答速度要件を満たせなくなる可能性が高い。

3. 技術難易度

　パブリッククラウドにクラウドシフトするための技術やエンジニアが不足している企業も多い。代表的な手法のリフトアンドシフトでは「リフト時」「リフト後」「シフト時」「シフト後」のそれぞれで以下のような課題が存在する。

• （a）リフト時の課題：ワークロードの実行環境変更に伴い、仮想マシンのカスタマイズが必要になる。オンプレミスネットワークからクラウドネットワークに変更するため、ネットワーク設計の再検討や変更が必要になる
• （b）リフト後の課題：パブリッククラウドの管理作法を新たに習得する必要がある。外部委託もしくはクラウドエンジニアの育成が必要になる
• （c）シフト時の課題：パブリッククラウドに適した形でワークロードの作り替えが必要になる。コンテナ化やマイクロサービス化などの手法がある
• （d）シフト後の課題：クラウドネイティブなワークロードを前提とした運用手法が必要になる（連載第2回以降で詳しく解説する予定）

リフトアンドシフトのフェーズ毎の課題（筆者作成）

　エッジコンピュータはこれらの課題をどのように解決するのだろうか。

エッジコンピュータとは

　エッジコンピュータはOT機器とITの連携という文脈で語られることも多いが、実はOT分野、クラウド、通信キャリアの3つの観点でも重要だ。OT分野のエッジコンピュータは、さまざまな異なるOT機器のインタフェースプロトコルを集約するゲートウェイとしての役割を担っており、これによりOT機器のデータ加工を可能にし、IT技術で活用可能になる。

OT分野のエッジコンピュータ（筆者作成）

　クラウド分野のエッジコンピュータは、クラウド技術の一部をオンプレミスのハードウェア上で実装する役割を担っている。また、クラウドの最新技術をオンプレミス上で享受することも可能にする。エッジコンピュータが下位レイヤーのデータを処理し、上位レイヤーであるパブリッククラウドにデータを間引きして送ることより、低遅延高速処理とセキュリティ向上を実現する。

クラウド分野のエッジコンピュータ（筆者作成）

　通信キャリア分野のエッジコンピュータは「MEC」（Multi-Access Edge Computer）と呼ばれることも多い。MECはモバイル端末などのデバイスの近くにエッジコンピュータを分散配置するもので、MECはデータセンターやクラウドの要素の一部を実装する役割を持つ。MEC上でデバイスからのリクエスト処理をすることで、通信遅延低減と上流ネットワークへの通信量を抑制できる。

　この場合、デバイスはモバイル端末であるため、物理的な移動が発生する。そのため、デバイスの接続先となるMECは一意に定まらず、MEC上のアプリケーションやデータ処理の切り替えを踏まえた設計や運用が必要となる。

通信キャリア分野のエッジコンピュータ（筆者作成）

　同じエッジコンピュータでもそれぞれの役割が異なる。そしてリフトアンドシフトの課題に対応するためにはクラウド分野のエッジコンピュータが重要になる。

　クラウド分野のエッジコンピュータは「（a）オンプレミス環境にハードウェアを設置」「（b）ワークロードを動かすための基盤 （仮想サーバなど）を実装」「（c）基盤とワークロードの両方をパブリッククラウドから管理」「（d）クラウドサービスの要素の一部も実装」といった特徴を有しており、これによりオンプレミス環境内で最新のクラウドサービスを高速かつセキュアに活用できる。

クラウド分野のエッジコンピュータの特徴（筆者作成）

　これは、クラウドをオンプレミス環境で動かすプライベートクラウドの一種といえる。エッジコンピュータが一般的なプライベートクラウドと違うのは「実装されている機能が限られている」「必要とされる物理的なハードウェアの台数が少なく、導入が容易」「パブリッククラウドと連携して透過的に一元管理が可能」といった点だ。

　クラウド分野のエッジコンピュータはパブリッククラウドと親和性が高く、簡易的なプライベートクラウドと見なすことができる。

クラウドシフトのハードルをさげる「段階的リフトアンドシフト」

　では、クラウド分野のエッジコンピュータを活用してクラウドシフトを進めるためのシナリオはどのようなものになるのだろうか。クラウド分野のエッジコンピュータをパブリッククラウドと連携する簡易プライベートクラウドと見なして解説する。

第1フェーズ：クラウド分野のエッジコンピュータへリフト

　クラウド分野のエッジコンピュータにはサーバ仮想化プラットフォームが実装されているため、そこにワークロードをストレートに移行できる。また、移行されたワークロードをパブリッククラウドから管理することも可能だ。

第2フェーズ：シフト

　クラウド分野のエッジコンピュータにはコンテナ管理プラットフォームの「Kubernetes」やクラウドサービスが実装されている。それを活用してワークロードをクラウドネイティブに作り替える。

第3フェーズ：パブリッククラウドへリフト

　クラウドネイティブ化されたワークロードをパブリッククラウドへ移行する。

段階的リフトアンドシフト（筆者作成）

　これは従来のクラウドシフトにおけるパブリッククラウドへのリフトを、クラウド分野のエッジコンピュータへのリフトに置き換えたものだ。

段階的リフトアンドシフトの効果

　段階的リフトアンドシフトにはどのようなメリット、デメリットがあるのだろうか。

　メリットは主に「技術難易度」の観点で大きいと筆者は考える。以下の図の（1）クラウド分野のエッジコンピュータ上へのリフトを例にすると、クラウド分野のエッジコンピュータには仮想サーバが実装されている。既存システムを仮想マシンとしてリフトするため、システム環境（構成やネットワークなど）の変更が少なくなり、リスク低減につながる。

　また、全てのシステムを一斉にリフトする必要は無く、準備ができたものからリフト可能だ。同じオンプレミス環境なので、問題発生時の切り戻しも容易であることから、リフトのハードルを下げることが可能となる。

　次に（2）クラウド分野のエッジコンピュータ上でのシフトを例にとる。これも準備ができたものからシフト可能だ。同一のサーバ上でのシフトであり、問題発生時の切り戻しの影響も少ない。

　最後に（3）パブリッククラウドへのリフトを例に考える。システムは既にクラウドネイティブワークロードとなっており、特定の実行環境に依存する部分は少なくなっているはずだ。そのため、パブリッククラウドへのリフトは容易であり、また、エッジコンピュータならではの高速低遅延処理を生かすため、（3）’ のようにそのままエッジコンピュータ上で動かし続けることも可能だ。

　このように段階を踏むことで、クラウドシフトのハードルやリスクを軽減させながら移行と人財育成の期間延長が可能となる。将来的な分散クラウドのシステム完成像から、バックキャストで方法論を整理するための期間として活用することもできる。

段階的リフトアンドシフトのフェーズ遷移（筆者作成）

　デメリットとしては「コスト」が挙がる。通常のリフトアンドシフトと比較してシステム移行のプロセスが増加するため、システム移行費用も増える。また、エッジコンピュータ自体を新たに導入するコストも必要だ。前述のメリットとのバランスを考え、企業に合った方法を選択することが大切だ。

　今回はオンプレミスに残っているワークロードをクラウドシフトするための新たな手法を解説した。次回は分散クラウドにおけるデータとアプリケーション配置を中心に、どのようなアーキテクチャが有効なのか解説する。