クラウドネイティブのトレンドにおける移行と災害復旧

コスト削減と業務の利便性のため、IT システムをクラウドに移行する企業が増えています。しかし、移行の過程では、新しい環境に直面することになり、インフラストラクチャの展開からクラウド プラットフォームまでの課題は非常に困難です。クラウド移行のセキュリティを確保するにはどうすればよいでしょうか?移行リスクを軽減するにはどうすればよいでしょうか?オンラインの安定性とアジャイル配信のバランスをとるにはどうすればよいでしょうか?これは、企業の IT 管理者が非常に懸念する問題となっています。

上記の質問に答えてくれる本日のゲストは、浙江モバイルのクラウド インテリジェンス プラットフォーム運用保守アーキテクトである Shi Junting 氏です。 Shi Junting 教授の研究成果と実践経験を集約することで、クラウドネイティブ環境に存在するセキュリティの問題を皆様に理解していただき、クラウド上で発生する可能性のある問題を回避し、クラウドネイティブ アプリケーションの運用安定性を確保できるようになることを願っています。

石俊婷

浙江モバイルクラウドインテリジェンスセンター運用保守アーキテクト

• アプリケーション最適化と SRE における 8 年間の経験。 2013年よりアプリケーションの運用保守、安定性向上、アーキテクチャ最適化等に従事。安定システム構築と分散システムアーキテクチャガバナンスに重点を置いています。新しいソリューションやテクノロジーを研究する意欲があります。彼は現在、浙江モバイルのオンライン システム アプリケーション アーキテクチャのガバナンスと安定性システムの構築を担当しています。浙江移動のカオスエンジニアリングの責任者として、中国移動グループ内でのドリル計画の実施を推進しています。

要点

個人的には、これらの問題を解決するには、アーキテクチャ設計、オンラインでの変更、耐障害性、オンラインガバナンスなど、プロセス全体を通じてエンタープライズレベルでの安定性システムを構築する必要があると考えています。つまり、安定性とは、障害耐性だけではなく、将来を見据えて高い価値を提供するためのアーキテクチャ設計から始めることも意味します。実践の中で、トラフィック再生、グレースケールリリース、カオスエンジニアリング、プレーンエスケープなどの効果的なプロジェクトを開発し、各プロセスのスムーズな接続を確保し、クラウド移行のリスクを最小限に抑えることに努めました。  

Q1 クラウド ネイティブでオンラインの安定性とアジャイル配信のバランスをとるにはどうすればよいでしょうか?

定常状態（安定性）と敏感な状態は、デュアル ステート モードと呼ばれます。私の理解では、俊敏性がクラウド ネイティブを生み出し、クラウド ネイティブが安定性を促進しました。すでに述べたように、クラウド ネイティブは、従来の「原子時代」から「ビット時代」への飛躍です。その具体的な形態はコンテナサポート＋マイクロサービスシステムであり、それをサポートする機能はDevOpsと継続的デリバリーです。これらすべては、コアビジネスの迅速な反復に基づいています。

そのため、運用側に十分な信頼を与えるための安定性システム/SREシステムが必要です。浙江モバイルは確かに長年にわたり安定性を模索してきました。当社は、比較的早い段階で運用・保守の変革を開始した伝統的な業界のひとつです。 R&D の観点から見ると、それは DevOps であり、私たちの観点から見ると、それは OpsDev です。この二つは矛盾するものではありません。全体的な安定性システムでは、基本的な障害防止システムに加えて、Ops はオンライン リリースを超えてアーキテクチャの制御と設計にまで進む必要があります。オンラインガバナンスと組み合わせることでのみ、完全な配達エスコートシステムを形成できます。関連するエンジニアリング プラクティスでは、複数の可用性ゾーンにわたるグレースケール リリース、カオス エンジニアリング、および自己インテリジェント ネットワーク機能を使用して、配信品質、オンライン品質、および運用品質を確保します。

Q2クラウド環境での災害復旧をどのように設計すればよいですか?

ここでは主にアプリケーション サービスの災害復旧設計について説明します。データベースの変更は比較的小さいものになると思います。アプリケーション アーキテクチャの場合、クラウド環境には、複雑なマイクロサービス呼び出し、コンピューティング リソースの制御とコンテナー クラウド プラットフォームの管理、および共通の依存関係を持ついくつかのパブリック コンポーネントが含まれます。企業ではデュアルプレーン/デュアル可用性ゾーン設計を採用することをお勧めします。ここの平面深さは比較的深いです。コンテナ クラウド (mesos、marathon、k8s) の管理から、パブリック コンポーネント、構成センター、登録センター、キャッシュ プラットフォームなど、そしてもちろん上位層アプリケーションまで、すべてをアクティブ/アクティブ デュアル プレーンに変換する必要があります。これにより、交通の流れを確保しながら、2 つの異なる環境で正確な切り替えと脱出を実現できます。

比較的豊富なリソースを持つ企業、またはコアビジネスにもう少しリソースを投資する意思のある企業は、10％〜20％の小さな平面を適応させて、より完全な脱出機能、リリース機能、およびドリル機能を形成することができます。

Q3 従来の災害復旧アーキテクチャと比較して、クラウド環境の災害復旧アーキテクチャ計画の類似点と相違点は何ですか?

個人的には、従来の災害復旧では主に高可用性が考慮されていると思います。デュアルコンピュータルーム、インスタンス冗長負荷などに焦点を当てるだけでよく、これは比較的単純で明確です。前の質問で述べたように、クラウド環境における災害復旧アーキテクチャでは、より深いレベルが考慮されます。従来のアーキテクチャの災害復旧要件を前提として、各レイヤー全体でプレーン レベルを分割する必要があります。さらに、インスタンス呼び出しレベルでのクラウド環境の可読性が大幅に低下するため、通常の高可用性では障害処理に一定の不利が生じる可能性があります。交通入口からのディスパッチ機能を備え、正確かつ自動的な飛行機脱出を提供できるユニット化設計を採用することをお勧めします。もちろん、可観測性などのサポート要件も高くなります。

Q4企業の元々の生産環境は複雑で、クラウドへの移行や業務再構築が困難でした。この点に関して、参考になる実装手順や技術的なルートはありますか?

R&D と SRE は二足歩行しており、同期して一緒に動く必要があります。なぜなら、大規模なシステムをクラウドに移行することは、実際には非常に大規模なプロジェクト、またはリスクの高いプロジェクトだからです。 R&D の観点からは、元の複雑な呼び出しを分解し、設計計画から分割の実現可能性を考慮する必要があります。このとき、 SRE は非機能的な観点からカードゲームやサンドボックスゲームに参加・実施する必要があり、R&D と競合することができます。エンジニアリング サポートの観点からは、カットオーバー プランの迅速なロールバックと古い環境の並行保存を確実に行う必要があります。新しい環境はカードゲームのシミュレーションに合格した後、オンラインになる前に実際の戦闘訓練の受け入れに入ります。この時点で、再生トラフィックを通じてシミュレーションおよび検証が可能です。リリース プロジェクトでは、グレースケール ローリング リリース モードを使用して、スムーズなカットオーバー移行を実現します。