ビジネスは継続され、移行が完了しましたが、Linode はどのようにしてライブ移行を実現するのでしょうか?

開発者がクラウド コンピューティング プラットフォームにワークロードを展開する場合、多くの場合、これらのサービスを実行する基盤となるハードウェアを考慮する必要はありません。ハードウェアのメンテナンスや物理的な制限は、人々が理想とする「クラウド」のイメージでは見えにくいものですが、ハードウェアは必然的に定期的なメンテナンスが必要となり、ダウンタイムが発生する可能性があります。このダウンタイムがお客様に伝わるのを防ぎ、クラウドの約束を真に実現するために、Linode は Live Migration と呼ばれるツールを提供しています。

ライブ マイグレーション テクノロジーを使用すると、サービスを中断することなく、Linode インスタンスを異なる物理サーバー間で移動できます。ライブ マイグレーション ツールを使用して Linode インスタンスを移動すると、移行プロセスは Linode インスタンスで実行されているプロセスからはまったく見えなくなります。ホストのハードウェアのメンテナンスが必要な場合、そのホスト上のすべての Linode インスタンスは、ライブ マイグレーションを通じて別のホストにシームレスに転送できます。移行操作が完了すると、顧客に影響を与えるダウンタイムを発生させることなく、物理ハードウェアの修復を開始できます。

これは、クラウド技術と非クラウド技術の分岐点となる決定的な技術となりつつあります。この記事では、このテクノロジーの詳細について詳しく見ていきます。

Akamai クラウドコンピューティングの詳細を読む

海外向けクラウドサービスならAkama i L i node！

ライブマイグレーションの仕組み

ほとんどの新しいプロジェクトと同様に、Linode のライブ マイグレーションは、多くの調査、多数のプロトタイプ、同僚や経営陣からの多大な支援から始まりました。最初のステップは、QEMU がライブ マイグレーションをどのように処理するかを調査することです。 QEMU は Linode が使用する仮想化技術であり、ライブマイグレーションも QEUM の機能です。したがって、私たちのチームの焦点は、同様のテクノロジーを再発明するのではなく、このテクノロジーを Linode に導入することです。

では、ライブ マイグレーション テクノロジーは QEMU でどのように実装されているのでしょうか?全体のプロセスは次の 4 つのステップに分かれています。

1. 移行するソース QEUM インスタンスとパラメータがまったく同じであるターゲット QEUM インスタンスを起動します。
2. ディスクのライブマイグレーションを実行します。データ転送プロセス中に、ディスクの内容に加えられた変更も宛先ディスクにコミットされます。
3. メモリデータのリアルタイム移行を実行します。移行プロセス中、メモリの内容に対する変更もターゲット メモリにコミットされます。このプロセス中にディスクの内容が変更されると、関連する変更がターゲット QEUM インスタンスのディスクにも送信されます。
4. カットオーバーポイントを実行します。 QEMU が安全に切り替えられるだけのメモリ ページがあると判断すると、ソースおよびターゲットの QEMU インスタンスが一時停止されます。 QEMU は、メモリ データの最後の数ページと、CPU キャッシュと次の CPU 命令を含むマシン状態をコピーします。次に、QEMU はターゲットの実行を開始し、ソース インスタンスが停止された状態からターゲット インスタンスを再開できるようにします。

これらの手順では、QEMU ライブ マイグレーションの実行方法の概要を示します。ただし、ターゲットの QEMU インスタンスをどのように起動するかを正確に指定するには、依然として非常に手動のプロセスが必要です。さらに、上記のプロセスにおける各操作は、正しいタイミングで実行する必要があります。

Linode がライブマイグレーションを実装する方法

QEMU 開発者が実装したテクノロジーを分析した後、それを Linode に導入する方法を検討する必要があります。その答えこそが、私たちの仕事の最優先事項です。

ライブ マイグレーション ワークフローのステップ 1 では、着信ライブマイグレーション接続を受け入れるために、ターゲット QEMU インスタンスを起動する必要があります。このステップを実装する際、当初の考えは、現在の Linode インスタンスの構成ファイルを取得し、それをターゲット コンピューターに適用することでした。理論的にはこれは単純なはずですが、さらに考えてみると、実際の状況ははるかに複雑であることがわかります。特に、構成ファイルは Linode インスタンスがどのように起動されるかを伝えますが、起動後の Linode インスタンスの完全な状態を必ずしも完全に記述するわけではありません。たとえば、 Linode インスタンスの起動後に、ユーザーはブロック ストレージデバイスをホットプラグして接続できますが、これは構成ファイルに記録されません。

ターゲット ホスト上に QEMU インスタンスを作成するには、現在実行中の QEMU インスタンスをプロファイルする必要があります。確認します 品質管理 このインターフェースは、QEMU インスタンスのレイアウトに関する豊富な情報を提供しますが、ゲスト システムの観点からインスタンス内で何が起こっているかを理解するのには役立ちません。たとえば、ローカル SSD とブロック ストレージの場合、ディスクがどこにリンクされているか、仮想ディスクがどの仮想化 PCI スロットに接続されているかのみを知ることができます。 QMP を照会し、QEMU インターフェイスを検査および分析した後、ターゲットの場所で同一のインスタンスを作成する方法を記述するプロファイルを構築できます。

ターゲット マシンでは、ソース インスタンスがどのようになっていたかについての完全な説明を受け取り、それをターゲット上で忠実に再現できますが、違いが 1 つあります。主な違いは、ターゲット QEMU インスタンスが、QEMU が着信移行を受け入れることを可能にするオプションを使用して起動されることです。

この時点で、ライブ移行の記録プロセスは基本的に終了しています。次に、QEMU がこれらの操作をどのように実装するかを確認する必要があります。 QEMU プロセス ツリーは、制御プロセスと複数のワーカー プロセスで構成されます。ワーカー プロセスのうちの 1 つは、QMP 呼び出しを返すか、ライブ マイグレーションなどのタスクを処理する役割を担い、他のプロセスはゲスト CPU に 1 対 1 でマッピングする必要があります。ゲスト環境は QEMU 側から機能的に分離されており、独立したシステムのように動作します。

この意味で、次の 3 つのレイヤーのコンテンツを処理する必要があります。

• 最初のレベルは管理レベルです。
• レイヤー 2 は QEMU プロセスの一部であり、すべての操作を処理する役割を担います。
• レイヤー 3 は実際のゲスト レイヤーであり、Linode ユーザーとのやり取りを担当します。

ターゲット インスタンスが起動し、受信移行を受け入れる準備が整うと、ターゲット ハードウェアはソース ハードウェアにデータの送信を開始するように指示します。ソースはこの信号を受信した後に処理を開始し、ソフトウェア内の QEMU にディスク コンテンツの転送を開始するように指示します。ソフトウェアは、ディスク転送の進行状況を自動的に監視して転送操作が完了したかどうかを確認し、ディスク転送が完了するとメモリの内容の移行を自動的に開始します。この時点で、ソフトウェアはメモリ移行の進行状況を監視し、メモリ移行が完了すると自動的にカットオーバー モードに切り替わります。上記のプロセスはすべてLinodeを通じて行われます データは40Gbpsのネットワーク経由で送信されるため、ネットワーク操作を迅速に完了できます。

カットオーバー: 主な手順

カットオーバー操作は、ライブ マイグレーション プロセスの最も重要な部分です。これを理解することでのみ、ライブマイグレーション操作を完全に理解することができます。

カットオーバーポイントでは、QEMU は、すべてがカットオーバーされ、ターゲット マシン上で実行される準備ができていることを確認しました。ソース QEMU インスタンスは両端を停止します。つまり、次のようになります。

1. ゲストシステムは「時間停止」です。ゲストが NTP などの時刻同期サービスを実行している場合、移行が完了すると NTP は自動的に時刻を再同期します。これは、システム クロックが数秒遅れる可能性があるためです。
2. ネットワーク要求が停止しました。ネットワーク要求が TCP 要求 (SSH や HTTP など) の場合、基本的に接続の中断は認識されません。ネットワーク要求が UDP 要求 (ストリーミング ビデオなど) の場合、少量のフレーム損失が発生する可能性があります。

時間とネットワークの両方の要求が停止されるため、切り替えはできる限り迅速に行う必要があります。ただし、カットオーバーを成功させるには、いくつかのチェックが必要です。

• ライブマイグレーションがスムーズにエラーなく完了することを確認します。エラーが発生し、ロールバックする必要がある場合は、ソース Linode インスタンスの一時停止を解除し、それ以上の操作を実行しないでください。開発中、私たちはこの分野で多くの実験を行い、多くのバグを修正しました。これは私たちにとって大きな頭痛の種でしたが、最終的には解決されました。
• ソースインスタンスでネットワークがオフになっており、ターゲットインスタンスで適切に接続されていることを確認します。
• 移行された Linode インスタンスがどの物理マシン上で実行されているかを、インフラストラクチャの残りの部分に明確にします。

切り替えプロセスには時間が限られているため、上記の操作をできるだけ早く完了したいと考えています。これらの問題を解決したら、カットオーバーを続行できます。ソース Linode インスタンスは自動的に「カットオーバー完了」信号を受信し、ターゲット インスタンスを実行します。宛先 Linode インスタンスは、ソース インスタンスが一時停止された状態から再開されます。ソース インスタンスとターゲット インスタンス上の残りのコンテンツはクリーンアップされます。将来、ターゲット Linode インスタンスを再度ライブマイグレーションする必要がある場合は、上記の手順を繰り返します。

エッジケースの概要

ライブ マイグレーションの実装のほとんどは簡単ですが、エッジ ケースを考慮すると、機能自体の開発は広範囲にわたっています。このプロジェクトの成功は、ツールの素晴らしいビジョンを信じ、タスクを完了するために必要なリソースを提供した経営陣のおかげであることは言うまでもありませんが、もちろん、プロジェクトが成功裏に完了できると信じていた多数の従業員の存在も切り離せません。

次の領域で多くのエッジケースが発生しました。

• 社内ツールを開発して、Linode カスタマー サポート チームとハードウェア運用チームのライブ移行作業を調整しました。これらのツールは、当時使用していた他の同様のツールと似ていましたが、開発に多大な労力を要したいくつかの違いもありました。

• ツールは、データセンター内のすべてのハードウェアを自動的に検査し、移行する必要がある各 Linode インスタンスに最適なターゲットとなるホストを決定する必要があります。この選択と決定を行う際に考慮すべき関連仕様には、使用可能な SSD ストレージ容量とメモリ割り当てが含まれます。
• ターゲット コンピュータの物理プロセッサは、受信する Linode インスタンスと互換性がある必要があります。特に、CPU には、実行するソフトウェアに不可欠な特定の機能 (CPU シグネチャと呼びます) が備わっている必要があります。たとえば、AES はハードウェア アクセラレーションによる暗号化機能を提供する関数の 1 つです。ライブ マイグレーションのターゲット コンピュータの CPU は、ソース コンピュータと同じ CPU タグをサポートしている必要があります。これは非常に複雑なエッジユースケースであることがわかったので、以下に私たちのアプローチについて説明します。

• エンドユーザーの介入やライブ移行中のネットワーク接続の喪失などの障害を適切に処理します。この情報については、以下で詳しく説明します。
• Linode プラットフォーム自体の変更に対応してください。これは継続的かつ長期的なプロセスです。 Linode プラットフォームが現在および将来サポートするすべての機能について、ライブ マイグレーションとの互換性を確保する必要があります。詳細については、以下をお読みください。

CPU タグ付け

QEMU には、ゲスト オペレーティング システムに CPU を提示するためのさまざまなオプションがあります。 1 つのオプションでは、ホスト CPU モデルと機能 (つまり、CPU タグ) をゲストに直接渡すことができます。このオプションを使用すると、ゲストは KVM 仮想化システムでサポートされているすべての機能を制限なく使用できます。 Linode が初めて KVM を採用したとき (ライブ マイグレーション前)、パフォーマンスを最大化するためにこのオプションを使用しました。しかし、このオプションは、ライブ マイグレーション機能の開発中に多くの課題をもたらしました。

ライブ マイグレーション テスト環境では、ソース ホストと宛先ホストは 2 台の同一のコンピューターです。しかし、現実の世界では、ハードウェア クラスターは 100% 同一ではなく、マシン間の構成の違いによって CPU マーキングが異なる場合があります。これは、プログラムが Linode のオペレーティング システムにロードされると、Linode がプログラムに CPU タグを提示し、プログラムがソフトウェアの特定の部分をメモリにロードしてそれらのタグを活用できるため重要です。 Linode インスタンスが CPU タグをサポートしていないターゲット マシンにライブ マイグレーションされると、プログラムはクラッシュします。これにより、ゲスト オペレーティング システムがクラッシュしたり、Linode が再起動したりする可能性があります。

マシンの CPU シグネチャがゲストにどのように表示されるかには、次の 3 つの要因が影響していることがわかりました。

• 購入した時期に応じて、CPU ごとに若干の違いがあります。 CPU メーカーが新しいハードウェアをリリースする時期によっては、年末に購入した CPU と年初に購入した CPU のマークが異なる場合があります。 Linode は容量を拡張するために新しいハードウェアの購入を続けていますが、2 つのハードウェア注文で同じ CPU を購入しても、CPU のマークが異なる場合があります。
• 異なる Linux カーネルは、QEMU に異なるフラグを渡す場合があります。特に、ライブ マイグレーションに参加しているソース マシンの Linux カーネルは、ターゲット マシンの Linux カーネルとは異なるフラグを QEMU に渡す場合があります。ソース マシン上の Linux カーネルを更新するには再起動が必要です。そのため、ライブ マイグレーションの前にカーネル バージョンをアップグレードしてもこの不一致を解決することはできません。そうすると、マシン上の Linode インスタンスのダウンタイムが発生するためです。
• 同様に、異なる QEMU バージョンは、表示される CPU フラグに影響を与える可能性があります。 QEMU を更新するには、コンピューターの再起動も必要です。

したがって、ライブマイグレーションを実装する場合は、CPU タグの不一致によってプログラムがクラッシュしないようにする必要があります。可能なオプションは 2 つあります。

• QEMU で CPU フラグをエミュレートします。しかし、これにより、本来は高速なソフトウェアの速度が低下する可能性があり、その理由を調査する方法はありません。
• 移行を実行する前に、ソース マシンから CPU タグのリストを収集し、ターゲット マシンにまったく同じタグがあることを確認します。この方法はより複雑ですが、ユーザー プログラムの実行速度には影響しません。最終的に私たちはこのアプローチを選択しました。

ソースとターゲットの CPU タグを一致させることを決定した後、次の 2 つのアプローチを組み合わせて最終的に目標を達成しました。

• 最初の方法はより簡単です。ソース ハードウェアのすべての CPU タグがターゲット ハードウェアに送信されます。ターゲット ハードウェアが新しい QEMU インスタンスをセットアップすると、少なくともソース Linode インスタンスと同じタグがあるかどうかが確認されます。一致しない場合は、ライブマイグレーションは発生しません。
• 2 番目の方法はより複雑ですが、CPU タグの不一致による移行の失敗を回避できます。移行を開始する前に、互換性のある CPU タグを持つハードウェアのリストを作成し、このリストからハードウェアを選択してターゲット マシンを作成します。

2 番目のアプローチは高速である必要があり、作業が複雑になります。場合によっては、900 台を超えるマシンの最大 226 個の CPU タグをチェックする必要がありました。 226 個の CPU フラグすべてをチェックするコードを書くのは非常に困難であり、そのコードは長期間にわたって保守される必要があります。しかし、Linode の創設者 Chris Aker 氏の驚くべきアイデアにより、ついに問題は解決しました。

この方法の鍵となるのは、すべての CPU フラグのリストを作成し、それをバイナリ文字列として表現することです。次に、ビットごとのand演算を使用して文字列を比較できます。このアルゴリズムを説明するために、次の簡単な例を使用できます。次の Python コードは、ビット単位のANDを使用して2 つの数値を比較できます。

 >>> 1 & 1 1 >>> 2 & 3 2 >>> 1 & 3 1

ビット単位のAND演算がなぜその結果を生成するのかを理解するには、まず数値を 2 進形式で表す必要があります。 10進数の「 2 」と「 3 」を2進数で表すとどのように処理されるかを見てみましょう。

 >>> # 2: 00000010 >>> # & >>> # 3: 00000011 >>> # = >>> # 2: 00000010

ビットAND は、 2 つの異なる数値の 2 進数の「桁」または「ビット」を比較します。この操作は、上記の数字の右端の桁から始まり、左に向かって行われます。

• 「 2 」と「 3 」の右端（最初の）ビットはそれぞれ「 0 」と「 1 」であり、0と1のビットごとのAND結果は「 0 」になります。
• 「 2 」と「 3 」の右から2番目の数字は両方とも「 1 」であり、1と1のビットごとのAND結果は「 1 」になります。
• これら 2 つの数値の他のすべてのビットは「 0 」であり、 0 と 0 のビットごとの AND 結果は「 0 」になります。

したがって、完全な結果のバイナリ表現は 00000010 となり、これは 10 進数では「 2 」になります。

ライブ マイグレーションの場合、CPU タグの完全なリストは、各ビットがタグを表すバイナリ文字列として表されます。ビットが「 0 」の場合、対応するタグが存在しないことを意味します。ビットが「 1 」の場合、タグが存在することを意味します。たとえば、1 ビットは AES フラグを表し、別のビットは MMX フラグを表すことができます。バイナリ文字列内のこれらのタグの位置は維持され、文書化され、その後、データセンター内のすべてのマシンで使用されます。

このリストは、CPU フラグが存在するかどうかを確認するための一連の if ステートメントを維持するよりもはるかにシンプルで効率的です。たとえば、追跡およびチェックする必要がある CPU フラグが合計 7 つあり、それらを 8 ビットの数値 (将来の拡張用に追加のビットを含む) に格納できるとします。たとえば、このような文字列は 00111011 のようになります。ここで、右端のビットは AES が有効であることを意味し、右から 2 番目のビットは MMX が有効であることを意味し、右から 3 番目のビットは他のフラグが有効であることを意味します。

次のコード スニペットでは、どのハードウェアがこれらのフラグの組み合わせをサポートしているかを確認できます。また、このコードは 1 サイクルで一致するすべての結果を返すことができます。比較が if ステートメントのセットとして実行される場合、目的の結果を得るためにより多くのサイクルが必要になります。ライブ マイグレーションのソース マシンに 4 つの CPU タグが含まれている場合、一致するハードウェアを見つけるのに 203400 サイクルかかります。

ライブ マイグレーション操作では、ソース コンピューターとターゲット コンピューターの両方の CPU タグ文字列に対してビット単位の AND演算が実行されます。両方のコンピューターの CPU ID 文字列が等しい場合、ターゲット コンピューターに互換性があることを意味します。このプロセスについては、次の Python コード スニペットを参照してください。

 >>> # The b'' syntax below represents a binary string >>> >>> # The s variable stores the example CPU flag >>> # string for the source: >>> s = b'00111011' >>> # The source CPU flag string is equivalent to the number 59: >>> int(s.decode(), 2) 59 >>> >>> # The d variable stores the example CPU flag >>> # string for the source: >>> d = b'00111111' >>> # The destination CPU flag string is equivalent to the number 63: >>> int(d.decode(), 2) 63 >>> >>> # The bitwise and operation compares these two numbers: >>> int(s.decode(), 2) & int(d.decode(), 2) == int(s.decode(), 2) True >>> # The previous statement was equivalent to 59 & 63 == 59. >>> >>> # Because source & destination == source, >>> # the machines are compatible

上記のコード スニペットでは、宛先マシンがソース マシンよりも多くのタグをサポートしていることに注意してください。ソースのすべての CPU タグがターゲット マシンに含まれているため、ターゲット マシンは互換性があると見なされます。これは、ビット単位のAND演算によって保証されます。

当社の内部ツールは、上記のアルゴリズムの結果を使用して、互換性のあるハードウェアのリストを作成できます。このリストは、当社のカスタマー サポート チームとハードウェア運用チームに提示され、これらのチームは社内ツールを使用してさまざまな運用タスクを調整できます。

• このツールを使用して、特定の Linode インスタンスに最も互換性のあるハードウェアを選択します。
• ターゲットを指定せずに Linode インスタンスのライブ マイグレーションを開始します。同じデータセンター内で最も互換性のあるハードウェアが自動的に選択され、移行がすぐに開始されます。
• 1 つのタスクでホスト上のすべての Linode インスタンスのライブ マイグレーションを開始します。この操作は通常、ホスト上でメンテナンス タスクを実行する前に実行されます。当社のツールは、すべてのインスタンスのターゲットを自動的に選択し、各インスタンスに必要なオーケストレーションを実行します。
• メンテナンスが必要なマシンのリストを指定すると、当社のツールはすべてのホストにわたるすべてのインスタンスのライブ マイグレーションを自動的に調整できます。

ソフトウェアを「実行」するには、多くの開発作業が必要です...

障害処理

ソフトウェア分野ではあまり議論されないトピックがあります。それは、障害を適切に処理することです。ソフトウェアは少なくとも「実行」できる必要があります。これを実現するには、ライブ マイグレーション機能の開発など、多くの開発作業が必要になることがよくあります。ツールが正常に動作しない場合にどうするか、その状況に適切に対処するにはどうすればよいかについて、私たちは多くの時間をかけて考えました。私たちは多くのシナリオを検討し、具体的な対応を決定しました。

• 顧客がCloud Managerから Linode の機能にアクセスしたい場合はどうすればよいですか?たとえば、ユーザーは Linode を再起動したり、インスタンスにブロック ストレージ ボリュームを接続したりすることができます。

解決策: 顧客はこれを実行できます。ライブマイグレーションは中断され、処理を続行できません。ライブマイグレーションは後で再試行できるため、この動作は適切です。

• ターゲット Linode が起動に失敗した場合はどうすればよいですか?

解決策: ソース ハードウェアに通知し、特別に設計された内部ツールを使用してデータ センター内の別のハードウェアを自動的に選択します。運用チームにも通知が送られ、障害が発生したターゲット ハードウェアを調査できるようになります。これは本番環境で以前にも発生したことがあり、ライブ移行では問題なく処理されました。

• 移行中にネットワーク接続が失われた場合はどうすればよいですか?

ソリューション: ライブ マイグレーションの進行状況を自動的に監視します。過去 1 分間に進捗がなかった場合は、ライブ マイグレーションはキャンセルされ、運用保守チームに通知されます。これはテスト環境以外では発生したことはありませんが、このシナリオに対しては十分な準備が整っています。

• インターネットの残りの部分がダウンしたが、ソースと宛先のハードウェアが引き続き実行され、通信しており、ソースと宛先の両方の Linode インスタンスが正常に機能している場合はどうなりますか?

回避策: ライブ マイグレーションがクリティカル ステージに到達しない場合は、ライブ マイグレーションが停止され、後で再試行されます。

重大な段階に達した場合は、移行は継続されます。これは、復元操作を続行するために、ソース Linode が停止し、ターゲット Linode が電源オンの状態である必要があるため重要です。

これらのシナリオはテスト環境でシミュレートされており、上記の動作はさまざまな状況で最適な対応であると考えています。

技術の変化に遅れを取らない

数十万回のライブマイグレーションを成功させた後、 「ライブマイグレーションの開発はいつ終わるのか」という疑問が湧くのは当然です。テクノロジーがますます広く使用され、時間の経過とともに改善されるにつれて、プロジェクトは永遠に続くように思えます。この質問に答える一つの方法は、プロジェクトの作業の大部分がいつ完了するかを考えることです。答えは簡単です。信頼性が高く、信用できるソフトウェアを生み出すという私たちの取り組みは、今後も長く続くでしょう。

Linode は時間の経過とともに新しい機能を追加するため、ライブマイグレーションがそれらの機能と互換性があることを保証するための作業を継続的に行う必要がある場合があります。いくつかの新機能を導入する場合、ライブ マイグレーションに関する新しい開発作業を行う必要はないかもしれませんが、機能が期待どおりに動作するかどうかをテストする必要がある可能性があります。一部の機能については、開発の初期段階でライブ移行に必要な互換性テストや関連作業を実行する必要がある場合があります。

他のほとんどすべてのソフトウェアと同様に、継続的な研究を通じて、同じことを達成するためのより良い方法を常に見つけることができます。たとえば、ライブ マイグレーション機能に対して、よりモジュール化された統合アプローチを開発すると、長期的にはメンテナンスの負担が確実に軽減されます。あるいは、ライブ マイグレーション機能を基盤コードに組み込み、Linode のすぐに使える機能にすることもできます。

私たちのチームはこれらすべてのオプションを検討し、Linode プラットフォームを動かすツールは健在であると確信しており、今後もツールの進化と成長を維持するために努力を続けます。

この記事の内容は大丈夫でしょうか？今すぐ Linode プラットフォームで試してみませんか?今すぐ登録すると、100 ドル相当の無料クレジットを獲得できることをお忘れなく。早速、この記事で紹介した機能やサービスを実際に体験してみましょう↓↓↓

海外向けクラウドサービスならAkama i L i node！

最後に、Akamai をフォローして、Web 配信パフォーマンス、セキュリティ、エッジコンピューティング、業界全体の開発動向の分野における Akamai の最新の技術的成果とソリューションについて学んでいただくことをすべての友人に歓迎します。