Amazon Web Services ブログ

Tag: Migration

CCOEを構築するときに避けるべき7つの落とし穴

Cloud Center of Excellence (CCOE)を設立することは、多くの場合、企業のクラウドへの移行を迅速に開始し、ベストプラクティスと長期的な適合性を考慮して移行をガイドするための優れた方法です。 そういった企業は、クラウドのベストプラクティスに関する専門家のチームを編成し、彼らのスキルとクラウドへの情熱を利用して、その企業の残りのクラウドトランスフォーメーションに緊急性を与えています。 AWSでは、CCOEを設立するときに組織がうまくいかない可能性のあるいくつかのやり方を特定しました。 このブログ投稿では、AWSのシニアパートナーソリューションアーキテクトであるNéstor GándaraとEric Linが、これらの落とし穴を回避し、CCOEの可能性を最大限に引き出す方法を示します。 ―Mark

Read More

Oracle Data Guard (Fast-Start Failover)とSAP NetWeaver – 高可用性設計とソリューション

はじめに 多くのSAPのお客様はまだオンプレミス環境で、OracleデータベースとさまざまなOS (IBM AIX、HP-UX、Red Hat Enterprise Linux / SUSE Linux Enterprise Server)の組み合わせで、ミッションクリティカルなSAPワークロードを稼働しています。お客様のクラウド導入のジャーニーの課題は、クラウドTCO(総所有コスト)削減のメリットをすぐに得るように、Oracleベースのワークロードを「リフト&シフト」というアプローチでそのまま移行することです。お客様はこのアプローチを選択し、2027年以降の長期的なSAP戦略を決定するまでの暫定的なステップとするパターンがよくあります。 移行準備の間によくある質問は、「AWSクラウドでOracleデータベースを高可用性構成にするにはどうしたらよいか」ということです。答えは、Amazon Web Services (AWS)では、Oracleネイティブとサードパーティソのリューションに分けられた複数のオプションがあります。

Read More
ITXパッケージ

AWS ITトランスフォーメーションパッケージ – 評価・移行計画立案・移行の3フェーズで、クラウドへの移行を成功させる

みなさん、こんにちは。AWS ソリューションアーキテクトの瀧澤です。 AWSへの大規模なシステムの移行を実現し、お客様のデジタルトランスフォーメーションをサポートするための「AWS ITトランスフォーメーションパッケージ(ITXパッケージ)」を紹介します。 これまで、AWSでは、Migration Acceleration Program (MAP)というマイグレーションをご支援するプログラムをご提供してきました。これはマイグレーションプロジェクトを評価(Assessment)フェーズ、移行計画立案(Mobilize)フェーズ、移行-マイグレーション&モダナイゼーション(Migrate & Modernize)フェーズに分け、評価フェーズにおけるクラウド移行の経済性評価や移行準備状況のアセスメントを行い、マイグレーション&モダナイゼーションフェーズにおいて、AWS利用料の一定利用率をクレジットで還元することでお客様の移行をサポートしてきました。しかし、お客様の声をお伺いすると、マイグレーションはDXにおける通過点に過ぎず、中でも次の6つの課題をお持ちであることが分かりました。

Read More

AWS DataSyncとAmazon FSxを使って1ヵ月でファイルストレージをAWSへマイグレーション

このブログはVaibhav Singh (Cloud Infrastructure Architect with AWS ProServe India)によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。   オンプレミスからクラウドへの移行では、さまざまなお客様がそれぞれに異なった環境を持っていて実現方法も異なります。あるお客様はオンプレミスで稼働しているワークロードの規模が小さかったり、あるお客様は複数のデータセンターに複数のストレージアレイを設置していたり、さらに複雑で膨大なセットアップを行っているお客様もいるかと思います。クラウドに移行する場合、現在のデータストレージ環境を調査することの難しさや、どのように始めればよいか戸惑うのは当然のことでしょう。 AWSプロフェッショナルサービスは、ダウンタイムを最小限に抑えながら、お客様のクラウドへの移行をサポートし、最も効率的で効果のある方法でクラウドソリューションを最大限に活用できるようにします。AWSは、アプリケーションやデータベース、バックアップやディザスタリカバリ(DR)のスタックを再設計することなく、ビジネスに最適な方法でデータをクラウドに移行することを支援します。 この記事では、10,000人以上の従業員を抱えるグローバル金融サービス企業のお客様が、AWSプロフェッショナルサービスによる迅速かつ安全なオンライン移行によって、どのようにしてクラウドへの移行を加速させたかを紹介します。このケースでは、お客様はAWS DataSyncとAmazon FSx for Windows File Server(Amazon FSx)を使用して、100TB以上のファイルストレージを迅速かつシームレスに移行することができました。

Read More

AWSだからできるRISE with SAPの豊富なモダナイゼーションパス

はじめに 先日、SAPはRISE with SAPを発表しました。RISE with SAPは、シングルテナントでSAPが管理するERP導入により、Intelligent Enterpriseを実現するため、より簡単にSAP S/4HANAへのアップグレードを可能にするサービスです。RISE with SAPは、お客様のクラウドジャーニーを実行するために必要なテクノロジーを、1つの契約にまとめて提供することで、SAP S/4HANAの導入をさらにシンプルにします。本サービスでは、RISE with SAPのコアサービスにおける標準的なプロダクションSLAを99.7%(非本番では99.5%)とし(追加費用により99.9%のSLAを実現)、SAP S/4HANAのオンプレミスでの導入と比較して、5年間の総所有コスト(TCO)を20%削減¹することができます。AWSは、RISE with SAPのクラウド・サービス・プロバイダー(CSP)の選択肢の一つとなります。

Read More

SAP on AWS: 2020年振返り

はじめに 2020年を振り返ると、どれだけ信じがたい出来事が起きたかということを認めなくてはなりません。全世界的にCOVID-19やその他の世界の出来事によって私たちの生活様式が変化し、多くの人々にとって困難なものとなりました。このパンデミックにより、企業は顧客や従業員のニーズを満たすために、ほぼ即座に運用上の変更を余儀なくされました。また、多くの企業がクラウドサービスの利用を始めました。 この数週間にわたり、毎年恒例のre:Inventカンファレンスの一環として、私たちは多くのお客様からの声を聞く機会がありました。その数社はSAPトランスフォーメーションのストーリーを世界へ共有するためのバーチャルステージを行いました。:

Read More

【開催報告】AWSセミナー マイグレーション事例祭

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 4月9日に、「AWS セミナー マイグレーション事例祭」を開催いたしました。株式会社グリー 様、株式会社CyberZ様、株式会社マッチングエージェント様、ニフティ株式会社様をゲストにマイグレーションを進める上で良かった点や苦労した点、クラウド化したことによる効果、また今後クラウドで実現したいことなどに関して語っていだきました。130名近くの方にお申込みいただき、開催当日も満足度の高いお声を多くいただきました。 AWS マイグレーション お客様事例紹介 「グリーにおけるAWS移行の必然性」 グリー株式会社 開発本部 インフラストラクチャ部 マネージャー 竹ヶ原 大地 様 [slides] 「分析環境を AWS Athena に移行とその後1年間の運用課題を振り返る」 株式会社CyberZ 開発局 engineer 茂木 高宏 様  [slides] 「 AWS での漸進的なアーキテクチャ変更 at タップル誕生」 株式会社マッチングエージェント  サーバーサイドエンジニア 島谷 宙伸 様 [slides] 「リフト&シフトから始めるレガシー脱却への挑戦~大規模コンテンツ配信サービスの移行実例~」 ニフティ株式会社 WEB 事業部 WEB サービス開発グループシニアエンジニア 伊達 乾 様, 添野 翔太 様 [slides] AWSセッション 「ビジネス基盤をクラウドに移行する際のポイント」 アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 諸岡 賢司, 上原 誠 [slides]   まとめ […]

Read More

ユニシスメインフレームからAWSへの5ステップでの移行

この記事はAstadia社のレガシーモダナイゼーションサービスのバイスプレジデントである Craig Marbleによるものです。 ユニシスメインフレームをお持ちの場合は、あなたはビジネスのバックボーンとして機能している信頼性の高いプラットフォームとアプリケーションポートフォリオの構築に投資していると思います。しかし、今日の技術環境は、ユニシス、メインフレームが提供できるよりも低コストで、より柔軟性と俊敏性を必要としています。 Amazon Web Services(AWS)のコンサルティングパートナーであるAstadiaでは、ユニシスメインフレームのアプリケーションワークロードを実行するための現代的で柔軟性のある選択としてAWSを利用しており、ユニシスメインフレームのアプリケーションとデータへの過去の投資を活用していることがわかりました。 慎重に計画、管理、実行すると、ユニシスメインフレームワークロードをAWSに移行することの利点は数多くあります。 Pay-as-you-goモデルのコスト削減に加えて、ユニシスメインフレームアプリケーションセットがAWSに完全に移行されると、実証済みのビジネスロジックを最新のテクノロジーと統合して、データ分析やモバイル対応を可能にし、新しい市場、顧客、パートナーにビジネスを拡大します。これを念頭に置いて、ユニシスメインフレームアプリケーションをクラウドに移行することは、贅沢と言うより必要にせまられてということのようです。 この記事では、ユニシスメインフレームアプリケーションをAWSに移行するのに役立つ5つのステップを紹介します。 元のアプリケーションのソースコードとデータを再利用し、最新のAWSサービスに移行することをお勧めします。 ユニシスメインフレームの移行を可能にするツールは、既存のコードをそのまま維持することができますが、一部のコンポーネントを置き換えてデータストレージを再考する必要があります。 このような最小限の変更のアプローチは、手作業の書き換えやパッケージの置き換えに比べてプロジェクトのコストとリスクを削減し、20年または30年の投資を活用しながら新しい市場を活用するための新技術との統合のメリットを享受します。ひとたび移行されると、アプリケーションは、既存のスタッフが現代化を進めるのに十分な特性をもつようになります。また価値ある知識野蓄積を新しいデベロッパーに伝えています。 ステップ1:ディスカバー まず、環境内のすべてのアプリケーション、言語、データベース、ネットワーク、プラットフォーム、およびプロセスをカタログ化して分析する必要があります。アプリケーション間のとすべての連携ポイントと、外部連携ポイントを文書化します。できるだけ多くの自動分析を使用し、すべてを一元的なリポジトリにまとめます。 Astadiaは、Micro Focus Enterprise Analyzerなどの商用分析ツールと独自に開発したパーサーを組み合わせて、従来のコードを迅速かつ効率的に分析します。この分析出力は、Astadia Code変換エンジンに供給される移行ルールを確立するために使用されます。これらのルールは、プロジェクト全体を通じて更新され、洗練されます。 ステップ2:デザイン すべてのソースコード、データ構造、および最終形の要件を分析した後、ソリューション設計をするときが来ました。設計には、以下の詳細を含める必要があります。 AWSインスタンスの詳細:インスタンスタイプについて言うと、汎用Tインスタンスは、開発、テスト、または統合環境に向いていますが、汎用Mインスタンスは本番環境、本番前環境、およびパフォーマンスが要求される環境に向いています。 トランザクション負荷:一般的な非機能要件ですが、1秒あたりのトランザクション数が多いなどのパフォーマンス要件、または迅速な応答時間は、メインフレームのワークロードの実行にとって重要な場合が多いです。このことはネットワーク、ストレージ、コンピューティングの設計とサイズ設定を慎重に行う必要があるということです。 バッチ要件:バッチアプリを動かすほとんどすべてのユニシスメインフレームは、通常I/O集約型で、ストレージやデータストアからのレイテンシーが非常に短い事が要求されます。これは分散システムの課題であるため、バッチインフラストラクチャは早期に設計してテストする必要があります。 プログラミング言語の変換と置換:移行対象先でサポートされていない言語や使用できない言語は、ツールで変換したり、新しい機能に置き換えることができます。 外部システムとの統合:ユニシスメインフレームは、一般的にサテライトやパートナーシステムのバックエンドまたは記録システム(SOR)であり、移行後にはプロトコル、インターフェイス、レイテンシー、帯域幅などの統合を維持する必要があります。 サードパーティのソフトウェア要件:各ISV(Independent Software Vendor)はAWS上で機能的に同等のソフトウェアを利用できる場合もあれば、そうでない場合もあるため、特定の移行パスの定義が必要です。 将来要件の計画:ビジネス、IT戦略、優先順位は、特に将来のパフォーマンスと統合機能に関わるため、アーキテクチャの決定を左右します。 ソースコードには、Sperry MAPPER、Burroughs LINC、COBOL、またはECLが含まれます。データストアには、DMS(ネットワーク接続)、DMSII(階層型)、またはRDMS(リレーショナル型)が含まれます。 このデザインがUnisys ClearPath Libraマッピングを探す方法は次のとおりです。 図2 – Unisys Libra(Burroughs)メインフレーム移行アーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。   同様のマッピングは、TIP、MASM、BIS(Mapper)、ECLを含むUnisys ClearPath Doradoシステムでも実行できます。 図2のアーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。 OpenMCSは、移行されたコードをサポートするUnisys COMSの必要なトランザクション処理機能を提供するAstadiaのメッセージ制御システムです。このメインフレームクラウドフレームワークは、コンピュートリソースとしてAmazon Elastic Compute Cloud(Amazon EC2)上で動作します。 ほとんどの場合、ユニシスメインフレームの階層型およびフラットファイルのデータ構造は、Amazon Relational Database Service(Amazon […]

Read More