サービスをクラウドに移行するためのヒント

サービスをクラウドに移行するためのヒント

ローカル環境からクラウドへの移行は簡単な作業ではなく、多くの側面が関係します。サーバー移行、データベース移行、アプリケーション移行、企業のビジネスをクラウドに移行するための方法と手順は何ですか?移行プロセス中に注意すべき問題は何ですか?この記事で答えが見つかります。

[[333232]]

1. クラウドに移行する理由

現在でも、ビジネスワークロードをローカルデータセンターに置いている中小企業は数多く存在します。業務量の増加に伴い、ローカルデータセンターでは徐々に欠点も見え始めています。企業の新規事業のニーズに応えることは困難です。さらに、設備の購入や更新には、企業が事前に多額の費用を費やす必要があります。多くの中小企業は圧力に耐えられない。クラウドに移行することで、ローカル データ センターが直面する問題の一部を回避できます。

  • 構築および運用コストの削減: 独自のサーバー インフラストラクチャをホストするには、ハードウェア、ソフトウェア、電力、および人員への多額の投資が必要です。クラウド ソリューションに移行すると、設備投資が大幅に削減されます。
  • ハードウェア更新コストの削減: ローカルでホストされているかホスティング プロバイダーでホストされているかに関係なく、ハードウェアの交換は複雑な作業となり、企業はすべてのハードウェア費用を一度に投資する必要があります。
  • ソフトウェアのサポート終了の問題への対処: アプリケーションは、サポートが終了する他のソフトウェアまたはオペレーティング システムに依存している可能性があります。 AWS に移行すると、これらの依存関係に対する拡張サポート オプションが提供され、リファクタリングの要件が軽減されます。
  • メンテナンス作業を簡素化: 多くのシステムでは、メンテナンス コストが開発コストを上回ります。クラウドモデルサービスを導入した後は、基本プラットフォームの保守はクラウドサービスプロバイダーの責任となります。
  • 投資リスクを効果的に管理: システムは開発プロセスのどの段階でも障害が発生する可能性がありますが、ハードウェアへの投資は開発の初期段階で行う必要があります。一度障害が発生すると、初期投資を回収することはできません。クラウドサービスを使用した試行錯誤のコストは低くなります。
  • 俊敏性と効率性: 実験の自由度と開発の迅速化。
  • 柔軟性: クラウドは弾力性と拡張性を備えており、オンラインでの容量拡張をサポートします。負荷サイズに応じて柔軟かつ拡張可能です。
  • グローバリゼーション: クラウド内の別のリージョンにビジネスを移行するのは非常に便利です。
  • 多様性:人工知能、機械学習、ビッグデータ、モノのインターネットなどの先進技術を初めて体験します。
  • セキュリティ: クラウド プラットフォームは、冗長性とマルチコピーのメカニズム、クラウド プラットフォーム専用のエンタープライズ レベルのファイアウォール、カスタマイズ可能なセキュリティ レベルの展開を採用しています。クラウドプラットフォームには、当社の事業の円滑な運営と、クラウドサービスがさまざまな地域の法律や規制に準拠していることを保証するためのさまざまなセキュリティサービスがあります。

2. 移行計画

企業が Amazon Web Services を使用すると、オンデマンドでリソースを効率的かつ安全に実行できます。数か月待つことなく、わずか数時間で、これまで以上に効率的かつ機敏にイノベーションを起こすことができます。企業がクラウドに移行する際に、既存のサービスをより迅速かつ効率的に移行したい場合、移行計画を策定する際にはどのような点に注意する必要がありますか?この記事では、Amazon Web Services 移行モデルについて体系的に説明します。

移行プロセス

クラウド移行の多くのケースでは、比較的標準的な移行プロセスを段階的にまとめてきました。これらのプロセスに従ってビジネスを移行すると、移行の効率が向上し、迂回を回避できます。

  1. リソース評価: ローカル ビジネス リソースを全体的に理解し、ビジネス インベントリを作成し、環境内の物理サーバーと仮想サーバーを記録する必要があります。
  2. 検出と分析: 分類されたリソースを分析して、クラウド移行に適しているかどうか、およびクラウド内に対応するサービス サポートがあるかどうかを判断します。
  3. 計画と設計: クラウドの要件が満たされている場合は、移行戦略を策定する必要があります。
  4. 移行と検証:移行、検証、業務の切り替えを実行します。
  5. 運用と最適化: クラウド サービスを使用してビジネスを管理および最適化します。

移住評価

計画を開始する前にクラウド移行の優先順位と目標を設定すると、移行をより成功させることができます。さらに、自動化されたクラウド移行ツールは、環境と依存関係に関する洞察を提供し、クラウド移行プロジェクトの計画に役立ちます。企業の移行計画段階では、移行の基本的な考慮事項であるビジネス要因、コンプライアンス要因、セキュリティ要因、プラットフォーム要因、人員要因など、複数の要因を体系的に評価する必要があります。

  • ビジネス要因: すべての主要な利害関係者が移行のビジネスケースとコミットメントをサポートしているかどうか、また移行作業に投資するための資金があるかどうかを確認するために、すべての主要な利害関係者を考慮する必要があります。
  • コンプライアンス要因: 企業がコンプライアンス基準を満たすアプリケーションを持っているかどうかによって異なります。
  • セキュリティ要因: データの機密性に関して企業が直面している主な課題と、どのような管理対策が実施されているかを検討します。
  • プラットフォーム要因: パイロット アプリケーションのセットを特定し、ワークロード所有者からのコミットメントを得る必要があります。
  • 人的要因: ビジネスのスキルと能力を検証する必要があり、業務の役割と責任が定義されているかどうかも確認する必要があります。

Amazon Web Services のクラウド移行評価ツールである Application Discovery Service を利用すると、ローカル データセンターで実行されているアプリケーション、それらの関連する依存関係、パフォーマンス プロファイルを自動的に識別できるため、独自のクラウド移行計画を作成できます。

この情報を使用して、サーバーをローカル アプリケーションにマップします。これにより、サーバー間の依存関係や通信を特定し、クラウド移行計画に必要なすべてのアプリケーション コンポーネントを含めることができるため、リスクが軽減され、スムーズな移行が保証されます。次に、サーバーを論理的にグループ化してアプリケーションを提示し、その要件と移行目標に基づいて各アプリケーションに適切なクラウド移行戦略を選択します。

移行戦略

評価要因を定義した後、企業にとって非常に重要な、計画フェーズでの最も重要な移行モデルの質問について説明します。この点に関して、Amazon Web Services では、保持、廃止、再ホスト、置き換え、再プラットフォーム化、リファクタリングを含む 6R 移行理論を参考までにまとめています。ビジネス アプリケーションごとに異なる移行戦略を採用できます。企業は、アプリケーションの評価に基づいてさまざまな移行戦略を選択できます。

  • 保持: 一部のアプリケーションはすぐに移行できないか、クラウドへの移行が許可されていないため、引き続きローカル データ センターに保持されます。
  • 廃止: 評価プロセス中に不要になったビジネスが見つかった場合は、データセンターから削除できます。
  • 再ホスト: 「リフトアンドシフト」移行とも呼ばれるこのコード不要のオプションを使用すると、既存のアプリケーションを AWS に迅速に移行できます。各アプリケーションは「そのまま」移行され、コードを変更するリスクやコストをかけずにクラウドを活用できます。
  • 置換: 既存のアプリケーションを置き換えます。たとえば、アプリケーションをクラウド内の SaaS サービスに置き換えることです。
  • 再プラットフォーム化: Windows を Amazon Linux に置き換えるなど、クラウド移行の一環としてプラットフォームを変更します。
  • リファクタリング: バックエンド データベース、ミドルウェアなどを変更するなど、アプリケーションをリファクタリングしてからクラウドに移行します。これは比較的複雑です。

移行プロセス中は、複数の移行モードを使用します。 1 つのアプリケーション スタックでも、企業は 2 ~ 3 個の「R」に遭遇する可能性があります。最低コストと最高の価値を実現するには、アプリケーションを完全に分析し、それらを組み合わせる必要があります。

III.移行サービスとツール

クラウドへの移行プロセスと移行プロセスで使用されるいくつかの戦略を理解した後、ローカル センターのアプリケーションをクラウドに移行し始めます。クラウド データ センターで最も重要な 3 つのインフラストラクチャ リソースは、コンピューティング、ストレージ、ネットワークであることは周知の事実です。これら3つのパートに基づいて、それぞれの移行方法と関連する注意事項を中心に紹介します。

ネットワーク移行

ローカル データ センターのネットワークは一般にプライベート ネットワークであり、そのほとんどはフラット ネットワークです。事業規模の大きい企業の中には、比較的複雑なネットワークを計画するために独自のネットワークエンジニアを抱えているところもあります。ネットワーク移行の複雑さは、主にローカル データ センターのネットワークの複雑さによって決まります。ローカル ネットワークを Amazon Web Services に移行する方法についても、さまざまな状況に応じて検討する必要があります。

Amazon Web Services では、VPC を使用してプライベート ネットワークを構築します。 VPC のさまざまな機能は、基本的に企業ネットワークのさまざまなニーズを満たすことができます。では、ネットワークをどのように設計すればよいのでしょうか?

  • 完全なレプリケーション: サーバーのプライベート IP がアプリケーションに埋め込まれます。全体的な移行ではネットワーク構成は変更されず、ハイブリッド クラウド モデルを使用する予定もありません。この部分では、同じ IP アドレス セグメントを持つ、ローカル データ センターとまったく同じネットワークを VPC 内に確立できます。ただし、NACL、セキュリティ グループなど、VPC の一部のセキュリティ設定はローカル センターでは使用できない場合があることに注意してください。
  • ハイブリッド クラウド モデル: 一部の企業は、アプリケーションの一部をクラウドに移行しており、将来的にはハイブリッド クラウド モデルを計画しています。この状況に対処するために、VPC 内のネットワークを設計し、その IP アドレス セグメントがローカル データ センターの IP アドレス セグメントと重複しないようにしました。 IP アドレス範囲を再計画しているため、各サブネットにさらに多くの IP アドレスを割り当てるようにしています。

ローカル データ センターのネットワーク冗長性と高可用性ソリューションを構成するには、高度なネットワークに精通したエンジニアによる構成と保守が必要です。ネットワークがクラ​​ウドに移行された後、これらすべては Amazon Web Services によって管理されます。同社の保守担当者は、保守に基本的なネットワーク知識のみを必要とするため、ネットワーク管理のハードルが下がり、コストが削減されます。

ワークロードの移行

ビジネス オペレーションをサポートするリソースをワークロードと呼びます。仮想マシン、データベース、アプリケーションなどをワークロード レベルで大まかに計画できます。次に、これらの部分に焦点を当てて、移行全体の中で最も重要な部分でもある移行プロセスについて説明します。

仮想マシンの移行

仮想マシンをクラウドに移行すると、ビジネスに大きな経済的負担をかける可能性がある更新サイクルを回避できます。準備が整ったら、2 つの方法で移行できます。移行戦略として Rehost を使用します。

最初の方法: Amazon Server Migration Service を使用して、仮想マシンをローカルまたは他のクラウド プラットフォームから Amazon Web Services に直接移行できます。 Amazon SMS は、ローカル仮想マシンを Amazon EC2 にデプロイできるクラウドホスト型 Amazon マシンイメージ (AMI) に段階的に複製するのに役立つ無料サービスです。レプリケーション プロセス全体を通じて、移行中に使用される S3 バケット、EBS ボリューム、データ転送料金、および EC2 インスタンスの実行料金のみを支払う必要があります。

2 つ目: VMWare Cloud on Amazon ソリューションを使用して、VMware 仮想マシンを Amazon Web Services に直接移行することもできます。つまり、既存の VMware ベースのワークロードは、移行時に書き換える必要がなく、クラウドのパフォーマンス、スケール、セキュリティのメリットを享受できるということです。

  • 予防
    • サーバー全体の移転となるため、帯域幅が十分かどうか、一時的に帯域幅を増やす必要があるかどうかを検討する必要があります。
    • コピー処理中は、一時ディスクが使用されるかどうか、および十分なストレージ容量があるかどうかを考慮する必要があります。
    • ファイアウォールの置き換え: 共有クラウドには物理的なファイアウォールがないため、Amazon Web Services のセキュリティ グループを使用して置き換えることを検討できます。
  • 価値
    • より高いコスト効率と、より最適化された構成をお楽しみいただけます。
    • 複数リージョンのノード選択。
    • 運用・保守の効率を向上し、IT 運用・保守の重点をビジネス中心にシフトします。

データベースサービスの移行

ローカル データ センターのデータベース サービスは通常、物理マシンまたは仮想マシン上で実行され、運用および保守担当者によって展開されます。データベースの移行については、主に次の考慮事項と解決策があります。

  • 移行戦略: データベースの場合、選択できる移行戦略は、再ホストと再プラットフォームです。
    • Rehost の場合、Amazon SMS を直接使用して移行を実行できます。
    • Replatform では、ローカルで独自に構築したデータベース サービスを Amazon Web Services のデータベース サービスに変換します。 Amazon Web Services には豊富なデータベース サービスがあり、基本的にリレーショナル データベースや非リレーショナル データベースを含む、市場にあるすべてのデータベースをカバーしています。
  • 予防
    • ファイル形式、文字セットの互換性要件、エンジンの互換性要件などの互換性要件。
    • サービスプロバイダーのデータベース名やテーブル名の予約語など、データ移行に関する制限。事業が影響を受けるかどうか、またどの程度影響を受けるか。サービスを一時停止する必要があるかどうか、またどのくらいの期間一時停止する必要があるか。
    • 移行ツールの利便性とサービスプロバイダーからのガイダンス。優れた移行ソリューションとツールは、手作業が可能な限り少なく、段階的に自動化される必要があります。
    • データ整合性検証: データ移行が完了した後、切り替える前に、データが正しく完全に移行されたことを確認するために、データ整合性検証を実行する必要があります。たとえば、一部のサービス プロバイダーは整合性の検証を提供できなかったり、検証に矛盾がある場合に具体的な情報を提供できなかったり、実際に問題を特定できなかったりします。
  • 価値
    • クラウドデータベースの高パフォーマンス、高信頼性、スケーラビリティ、柔軟性
    • 大規模なイノベーション
    • バックアップ、拡張、移行などの機能があります。
    • DBA はデータベースのインストール、操作、高可用性、バックアップなどを管理する必要がなくなり、データベースの最適化に集中できるようになります。

再ホスト移行の場合、Amazon SMS ツールを使用して簡単に完了できますが、データがリアルタイムで同期されないため、データの遅延が発生する可能性があります。そのため、一般的には、従来の自社構築データベースにはないいくつかの利点があるクラウド内のデータベースを使用することをお勧めします。

Amazon Database Migration Service (Amazon DMS) は、リレーショナル データベース、データ ウェアハウス、NoSQL データベース、その他の種類のデータ ストアの移行を容易にするクラウド サービスです。 Amazon DMS を使用すると、データを Amazon Web Services に移行したり、ローカルインスタンス (Amazon Web Services を通じて設定) 間で移行したり、クラウドとローカル設定の組み合わせ間で移行したりできます。 DMS サービスを使用すると、ソース データベースとターゲット データベースのデータがリアルタイムで同期され、継続的に実行されることを保証できます。このモデルを使用すると、データベース移行のダウンタイムをゼロにすることができます。

ユーザーによっては、Oracle から Aurora MySQL に変換するなど、クラウドに移行した後にデータベース エンジンを変更したい場合があります。この場合、Amazon Schema Conversion Tool サービスを使用して完了することができます。 SCT を使用すると、より多くのメモリが消費されます。メモリパフォーマンスを向上させると変換速度が向上しますが、デスクトップ コンピューターのメモリ リソースの消費量も増加します。

アプリケーションの移行

アプリケーションをクラウドに移行するプロセスでは、通常、既存のビジネス システムの変革と新しいビジネス システムの構築という 2 つのシナリオに直面します。新しいビジネス システムは、クラウド アプリケーションの標準要件に従って設計、開発、コーディング、テストするだけでよく、実装も比較的簡単です。既存のビジネス システムをクラウドに移行するには、既存のビジネス システムを変革する必要があります。

移行戦略:

    • 再ホストの場合、Amazon SMS サービスを使用すると、アプリケーション テクノロジー スタック全体をクラウドに簡単に移行できます。この移行は比較的簡単です。移行が完了したら、バックエンド データベース情報を変更し、DNS サービスをオンラインに切り替えることができます。
    • リファクタリングの場合、この状況には多くの作業が必要になります。アプリケーションのパフォーマンスとセキュリティを向上させるには、Lambda、API GateWay、Elastic Beanstalk などのクラウドネイティブ サービスと完全に互換性を持たせるために、アプリケーション コードをリファクタリングする必要があります。
  • 予防
    • 関連するアプリケーションのロードマップはありますか?
    • この申請に関連する費用はいくらですか?
    • サービスの可用性を高めるために利用できる改善オプションは何ですか?
    • このアプリケーションを変更しないことで何かリスクはありますか?
    • このアプリケーションは組織の技術目標と一致していますか?
  • 価値
    • クラウドネイティブサービスが利用可能
    • クラウドのDepOpsツールを使用すると、アプリケーションのテストとリリースを高速化できます。
    • 運用および保守開発者は、アプリケーション環境の構成を管理する必要がなくなり、アプリケーションコードの開発に集中して効率を向上できます。

アプリケーションをクラウドに移行する場合、通常はまずクラウド内に完全なアプリケーション環境を構築し、プログラムがテストされるのを待ってから、DNS を変更してアプリケーションのクラウドへの移行を完了します。アプリケーションが安定したら、段階的かつ計画的にローカル センターから削除できます。

コンテナ移行

近年のコンテナの普及により、コンテナ プラットフォーム上でサービスを実行する企業が増えています。コンテナが単一のマシン上で実行される場合、通常は docker コマンドを使用して直接実行するか、docker-compose を使用します。複数のマシンで実行されるコンテナ サービスの場合、現在人気のコンテナ オーケストレーション サービスである Kubernetes を主に使用します。

コンテナの特性上、プログラム実行環境全体をイメージにパッケージ化することができます。実行環境を個別に構成する必要がなくなりました。この機能により、コンテナ内で実行されているアプリケーションをクラウドに移行することがはるかに簡単になります。ユーザーは、クラウドへの移行を完了するためにコードを変更する必要はありません。

では、Amazon Web Services ではどのようなコンテナ プラットフォームを選択できるのでしょうか?ローカルに構築されたコンテナ プラットフォームと比較した利点は何ですか?

Amazon Web Services のクラウド プラットフォームには、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の 2 つのコンテナ オーケストレーション ツールがあります。

  • アプリケーションが単一のマシン上で実行されている場合、クラウドでは ECS が最適な選択肢です。 ECS は、クラスター上で Docker コンテナを簡単に実行、停止、管理できる、スケーラビリティが高く高速なコンテナ管理サービスです。 ECS は、Identity and Access Management (IAM)、Amazon Virtual Private Cloud (VPC)、Amazon Route 53 などの Amazon サービスと緊密に統合されており、社内および顧客のミッションクリティカルなサービスをサポートするために、セキュリティ、信頼性、可用性の面で広範囲にテストされています。
  • アプリケーションが Kubernetes 上で実行される場合、クラウドでの最適な選択肢は EKS です。これは、Kubernetes を実行するための最も安全で信頼性が高く、スケーラブルな方法です。 EKS は、複数のアベイラビリティーゾーンにわたって実行されるスケーラブルで可用性の高いコントロール プレーンを提供し、単一障害点を排除します。 EKS はアップストリーム Kubernetes を実行し、Kubernetes 準拠として認定されているため、コミュニティのオープンソース ツールのすべてのメリットを享受できます。

Amazon Web Services でコンテナを実行する場合も、選択できるプラットフォームが 2 つあります。まず、サーバーを管理するかどうかを選択できます。コンテナを使用したサーバーレスコンピューティングが必要な場合は、AWS Fargate を選択してください。コンピューティング環境のインストール、構成、管理を制御する必要がある場合は、Amazon EC2 を選択してください。

Fargate は、ECS と EKS を介して Amazon でコンテナを実行するためのお客様にとって推奨される方法です。 Fargate はコンテナ向けのサーバーレス コンピューティングを提供し、アプリケーションの構築に集中できるサービスであるため、顧客に好まれています。 Fargate を使用すると、プロビジョニングおよび管理するサーバーがなくなり、設計によるアプリケーション分離によってセキュリティが向上し、アプリケーションごとにリソースを指定して料金を支払うことができます。

  • Amazon コンテナ プラットフォームの利点
    • 低コスト: コストを節約するために、基盤となるリソースとしていくつかのスポットインスタンスを選択できます。
    • エンタープライズ対応
    • 柔軟な拡張: 独自に構築された Kubernetes と比較して、クラウド内の EKS には Cluster AutoScaler 機能があり、負荷に応じてクラスター内のサーバー数を拡張できます。 ECS では、キャパシティー プロバイダーが基盤となるコンピューティング リソースの柔軟なスケーリングを提供します。
    • 信頼性の向上: ECS および EKS のコントロール パネルは Amazon Web Services によって完全に管理され、サービスの可用性は Amazon Web Services の専門技術チームによって維持されます。
    • ネットワーク: Amazon VPC CNI を使用してコンテナまたはポッドに VPC IP を付与し、ネットワーク パケットを排除してネットワーク パフォーマンスを向上させます。
    • 負荷分散: Amazon ALB を使用すると、トラフィックをコンテナまたはポッド IP に誘導でき、k8s クラスターはサービス分散を節約し、パフォーマンスを向上させることができます。
    • 権限: コンテナまたはポッドに IAM ロールレベルの権限を直接付与して、他の Amazon サービスに安全にアクセスすることができます。

では、これほど多くのサービスがある場合、どのように選択すればよいのでしょうか?

  • まず、非分散アプリケーション、つまり単一のコンテナサービスの場合は、ECS + EC2 プラットフォームを選択することをお勧めします。 ECS はコンテナの設定を簡素化し、コンテナ管理のハードルを下げます。ユーザーは、コンテナ操作の要件に応じてタスク定義を設定するだけで済みます。 EC2 を管理したくない場合は、EC2 + Fargate を選択することをお勧めします。
  • k8s プラットフォームで実行されるアプリケーションの場合、EKS + EC2 プラットフォームが推奨されます。コストを節約するために、スポットインスタンスを組み合わせて開始することもできます。ローカル k8s で使用される yaml ファイルは、特別な変更を加えることなく EKS で直接実行できます。移行全体は比較的簡単です。 ECS と比較すると、運用・保守担当者にはより高いコンテナ オーケストレーション スキルが求められます。トラフィックの変動が大きいアプリケーションについては、Fargate プラットフォーム上で実行し、基盤となるハードウェアを弾力的にスケーリングできます。

データ移行

ここで言及するデータは主に、静的に保存されたデータと、S3 に転送する必要がある一部のアーカイブされたデータを指します。データ移行ツールの選択では、主にデータの量とローカル データ センターの帯域幅を考慮します。組み合わせによって必要な移行ツールは異なります。

  • Amazon DataSync は、オンプレミスのストレージと Amazon S3 または Amazon Elastic File System (Amazon EFS)、または Amazon FSx for Windows ファイルサーバー間のデータ移行を簡素化、自動化、高速化するデータ転送サービスです。 DataSync はオンプレミスのエージェントを使用して NFS ファイル システムに接続し、スクリプトの作成や管理をすることなく、ファイル データを迅速に移行します (オープン ソースのコピー ツールよりも最大 10 倍高速)。 DataSync は、完全な初期コピー、増分転送、および転送されたデータの検証を実行できます。利用可能なネットワーク帯域幅がある場合、DataSync はファイルベースのデータを移行する比較的簡単な方法です。
  • Amazon Transfer for SFTP ( Amazon SFTP) は、セキュア ファイル転送プロトコル (SFTP) を使用して Amazon Simple Storage Service (Amazon S3) ストレージとの間でファイルを転送できる、完全に管理された Amazon Web Services サービスです。 SFTP は、セキュア シェル (SSH) ファイル転送プロトコルとも呼ばれます。
  • Amazon Snowファミリーは、厳しい非データセンター環境で運用を実行したり、大量のデータをオフプレミス環境に移行したり、一貫したネットワーク接続が不足している状況に遭遇したりする必要があるお客様を支援します。 Snow ファミリーは、Amazon Snowcone、Amazon Snowball、Amazon Snowmobile で構成されており、さまざまな物理デバイスと容量ポイントを提供します。そのほとんどにはコンピューティング機能も組み込まれています。これらのサービスにより、Amazon Web Services のストレージとコンピューティング能力をコスト効率よくローカルで使用し、データを効率的に転送して移行を加速できます。

データベースと帯域幅を通じてクラウドにデータをアップロードするのにかかる時間を簡単に見積もることができます。企業は自社の能力に応じてさまざまなツールを選択できます。比較的少量のデータの場合、DataSync、SFTP、そしてもちろん Amazon CLI を使用してデータを S3 に転送できます。比較的大容量でネットワーク経由で転送するのに時間のかかるデータの場合は、Snow シリーズを使用してデータを転送できます。

4. 最適化

AWS セキュリティ管理サービスを使用してクラウド環境を管理し、クラウド環境内のアプリケーションを管理および監視します。移行中にこれらのサービスを使い始め、移行後も一部を引き続き使用して、一貫したハイブリッド クラウド エクスペリエンスを確保します。

  • クラウドコスト管理: AWS 請求およびコスト管理は、コストを監視し、請求書を支払うのに役立つ機能を提供する Web サービスです。 Amazon Web Services (AWS) は使用量に基づいてアカウントに課金するため、使用した分だけ支払うことになります。
  • Amazon Web Services を使用してコストを節約: Amazon Web Services から RI を購入し、Savings Plans を使用して Compute Optimizer の推奨事項を参考に仮想マシンのサイズを調整し、最高の使用率を達成して価値を最大化します。
  • アプリケーションの最新化を加速: 節約したリソースを使用してクラウド機能を追加し、クラウド内のワークロードを徐々にサーバーレス モデルに移行してアプリケーションを最新化します。

V. 安全と管理

Amazon Web Services は、顧客のビジネスのセキュリティを非常に重視しています。 Amazon Web Services には、アプリケーションとデータのセキュリティを保護するためのさまざまなセキュリティ サービスがあります。ここでは、よく利用されるサービスのいくつかを簡単に紹介します。

  • 業界をリードするセキュリティ: Amazon Security Hub は、Amazon Web Services リソースのセキュリティ状態を包括的に表示します。 Security Hub は、AWS アカウントとサービス全体のセキュリティ データを収集し、セキュリティの傾向を分析し、AWS 環境全体のセキュリティの問題を特定して優先順位を付けるのに役立ちます。
  • クラウドの状態を監視および分析する: Amazon CloudWatch を使用して、クラウドアプリケーション、インフラストラクチャ、データの状態とパフォーマンスを追跡します。さまざまなソースからデータを簡単に収集し、豊富な洞察を得ることができます。
  • 仮想マシンを効率的に管理: Systems Manager を使用すると、コマンドのバッチ実行、運用管理、アプリケーション管理、操作と変更、インスタンスとノードなど、多数の仮想マシンを一括して簡単に管理できます。

6. 顧客事例

著者はかつて、携帯電話のアプリデータを分析することを主な業務とするデータ分析会社で働いていました。これまでの事業はすべて上海のデータセンターで行われていました。同社のアプリケーションは主にJavaプログラム、データベースにはMySQLやOracleが含まれ、ビッグデータ処理プラットフォームは複数の物理マシンを使用して自社構築したHadoopクラスターでした。

クラウドに移行する前に、一時的にプロジェクトを引き受けると、IDC リソースが対応するサービスをタイムリーかつ効果的にサポートすることが困難になります。企業は、ハードウェア(サーバー、ファイアウォール、スイッチなどの関連する基本ハードウェアを含む)を購入し、機器を棚に置き、ネットワークを計画し、システムをインストールして構成し、多くの手動操作とメンテナンスを行う必要があります。全体のサイクルには少なくとも半月~1 か月かかります。

トレーニングセッションの後、顧客はクラウド コンピューティングの機能について学び、自社の一部のビジネスにおけるクラウド移行の評価を開始しました。お客様は半月でローカルデータセンターのワークロードを整理してリスト化し、Amazon Web Services が提供する移行戦略とベストプラクティスに基づいて、ビジネスを段階的にクラウドに移行しました。多くのビジネスは、ローカルデータセンターのビジネスを徐々に置き換えるために、段階的にクラウドに移行する必要があることに留意する必要があります。クラウド移行プロセス中に、顧客は一部のアプリケーションを最適化および再構築して、クラウドネイティブ サービスに適したものにしました。

Amazon Web Services を使い始めてほぼ 1 年が経ち、お客様はクラウド サービスの利点を十分に体験しました。

  • ハードウェアの導入にかかる時間を節約し、サービス開始時間を短縮: お客様は、ハードウェアの調達、棚の導入、システムのインストールに多くの時間を費やす必要がなくなります。機器の立ち上げ時間は数週間から1時間未満に大幅に短縮されます。
  • 簡素化されたデータベース管理: RDS や非リレーショナル データベースを含む、自社で展開したすべてのデータベースをクラウド データベースに切り替えました。 MySQL については、Amazon Aurora Serverless データベースを直接採用しました。データベース構成の見積もりについて心配する必要がなくなりました。業務負荷に応じて自動的に拡張・縮小されるため、メンテナンスの負担が大幅に軽減されます。 DBA は、データベースの導入、高可用性、バックアップ、メンテナンスに労力を費やす必要がなくなりました。これらのタスクは、クリックしてクラウドに記録するだけで完了できます。 DBA が業務における作業技術を最適化することで、人件費が大幅に削減され、作業効率が向上しました。
  • アプリケーション起動の効率を向上: クラウドに移行する前は、Java プログラムであったため、アプリケーションの展開は比較的面倒でした。新しいプログラムを起動するたびに、Tomcat を構成する必要がありました。ポートを共有できなかったため、ポートを変更するには各 Tomcat の設定を変更する必要がありました。時間が経つにつれて、Tomcat はどんどん大きくなり、管理が非常に不便になりました。いくつかのアプリケーションをリファクタリングし、クラウドに移行しました。単純な機能を持つ一部のアプリケーションについては、基盤となるサーバーを意識することなく、Lambda にデプロイし、API Gateway を通じてトリガーしました。アプリケーションの別の部分は Elastic Beanstalk に直接デプロイされており、開発者は環境の設定に時間を費やすことなく直接デプロイできます。アプリケーションの他の一部は ECS 上に配置され、コンテナ テクノロジの使用により、展開の効率も大幅に向上しました。
  • 全体的なコストの節約: クラウドに移行すると、コストの節約も非常に大きくなります。コスト削減はおよそ 40% に達すると見積もっています。これは主に、クラウド コンピューティングの柔軟性、弾力性、低コストによるものです。事前に多数のハードウェアを事前構成したり、多額の費用をかけたりする必要はありません。長時間実行される一部のサービスについては、コストを節約するためにリザーブドインスタンスを購入しました。当社のビッグデータ プラットフォームを例に挙げてみましょう。以前は、多数のサーバーで構成されるクラスターがありました。クラスターの使用率は高くありませんでしたが、それなしではできませんでした。クラウドに行った後、EMRサービスを直接購入しました。 Amazon Web ServicesにはSpotと呼ばれるインスタンスの種類があり、コストの最大90%を節約できることがわかりました。ビッグデータワークロードでは、基本的にサーバーの80%がスポットインスタンスです。分析後、すべてのインスタンスが破壊されます。この機能だけでは、多くのコストを節約できます。

クラウドの利点はこれをはるかに超えています。たとえば、セキュリティの観点から、さまざまなセキュリティサービスが当社のビジネスの円滑な運用を保証し、初めて高度なサービスを使用できます。機械学習などの他のサービスを非常に便利に使用できます。それは私たちの仕事を減らすだけでなく、企業にとって大きなコストを節約します。

さらに、Amazon Web Servicesは、期間限定で1,000人民元の移行ギフトパッケージを思慮深く準備しました!

クリックして受信:

2020年5月24日から2020年10月30日まで、Amazon Web ServicesはCloud Migrationの顧客に独占的な利点を提供します。それらを登録して、1,000人民元(北京地域アカウントまたはNingxia地域アカウントの場合)サービスクレジットをAmazon Webサービスアカウントに直接充電して、サービス消費を相殺し、複数のクラウド移行アプリケーションシナリオを簡単に体験できるようになります。

PS: Amazon Web Servicesクラウド コンピューティング コミュニティが設立されました。ここでは、Amazon Web Servicesクラウド コンピューティングの最新の開発についてすぐに理解し、関連する技術情報を入手できるようお手伝いしますグループに参加したい場合は、QRコードをスキャンして返信してください[ Amazon Web Services ]。 24 時間以内にグループへの参加が承認されます。

<<:  クラウドコンピューティング半月刊第83号 - Kubernetes Ingress Controller ContourがCloud Native Computing Foundationのインキュベーションプロジェクトに

>>:  Hehe Informationはテクノロジーと温かさでAIを活用し、世界とつながる

推薦する

2012 年上半期の Baidu SEO イベントの概要

みなさんこんにちは。私は陳紅然です。 2012 年上半期、Baidu は SEO 分野で一連の動きを...

コンテナ内の JVM リソースを安全に制限するにはどうすればよいですか?

[[254653]]序文Java と Docker の組み合わせにより、アプリケーションのパッケー...

sharktech: 10% 割引コード/40g 高防御/98 ドルから Los Angeles E3-1270v2

ロサンゼルス データ センターの Sharktech の E3-1270v2 シリーズは現在 10%...

2019年のソーシャルメディアフィード広告のトレンド

近年、情報フロー広告市場は熾烈な競争を繰り広げており、インターネット大手も中小企業もトラフィック獲得...

コンテナ クラウド プラットフォームにマイクロサービスをデプロイするときに API ゲートウェイを選択するにはどうすればよいですか?

マイクロサービスはますます普及しており、ますます多くの企業がマイクロサービス アーキテクチャを採用し...

GKE セキュリティ: クラスターを保護するための 10 の戦略

セキュリティは、構成の複雑さと脆弱性の多さにより、Kubernetes が直面している主な課題の 1...

Geek Host: 35% 割引、月額 39 元から、香港 cn2 vps (50M)、シンガポール cn2 vps (50M)、米国高防御 vps

Geek Host は中国の老舗企業です。シンガポールに新しいサーバーを立ち上げ、米国の高防御 VP...

Bilibiliの富の夢はどこにあるのでしょうか?

BilibiliでUPホスト/フルタイムUPホストになるとどれくらいのお金を稼ぐことができますか? ...

Baidu Shareが次世代のSEOツールになる

2012年もSEOは引き続き人気が高まり、中小企業にとってSEOが激戦区になることが予想されます。 ...

オープンプラットフォームを利用してビジネスフォーラムを立ち上げる方法:ルールの設定が最も重要

「オープン性と統合による勝利」円卓フォーラム(写真はテンセントテクノロジー提供)テンセントテクノロジ...

ハッカーが戻ってきた:電子商取引のユーザーデータが再び販売されている

電子商取引業界関係者によると、電子商取引企業の大量のユーザーデータが再び市場に現れ、非公開で売買され...

Vanclの考察:インターネットプロモーションを諦めることは、実は降伏すること

今年の「中国の声」を見ましたか?昨年の「中国の声」の熱心なファンであるシャオ・ルーさんは周りの同僚に...

SEOではキーワードを分析する必要はなく、オーディエンスを分析するだけで十分です。

このタイトルは、多くのいわゆる SEOER を間違いなく冷笑させるでしょう。なぜでしょうか? 多くの...

電子商取引市場調査の観点から百度有為の必然的な失敗を考察する

電子商取引市場調査の観点から百度有為の必然的な失敗を考察するBaidu Youa は、日常生活の消費...