Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

【 AWS 新リージョン】 AWS 大阪ローカルリージョンが本日より利用可能になりました

本日 日本で2番目、ローカルリージョンとしては AWS 初となる、 Asia Pacific (Osaka) Local Region(以下、AWS 大阪ローカルリージョン)がご利用いただけるようになりました。 2017 年 5 月 31 日 AWS Summit Tokyo 2017 の基調講演にて、 2018 年より利用できるお知らせをしました。AWS 東京リージョンをお使いのお客さまにおいては、規制対応のため補完的なインフラストラクチャを準備し、アベイラビリティゾーン間を地理的に離す必要のある特定のアプリケーションの運用が可能になる点、多くの反響をいただきました。 AWS 東京リージョンが開設した 2011 年から、お客様は、同リージョンの 4 つのアベイラビリティゾーンを利用することで、いずれか 1 つのデータセンターで障害が発生した場合でも支障をきたさない、優れた耐障害性と高可用性を持つアプリケーション構築が可能になりました。すべての AWS リージョンは、複数かつ地理的に分離されたアベイラビリティゾーンから構成されます。アベイラビリティゾーンとは、 1 つの障害が可用性に影響を与えるリスクを大幅に減らすために、十分地理的に離れた地点に位置する一方で、迅速なフェイルオーバーが求められる事業の継続性に関わるアプリケーションのニーズを満たすために、十分近い距離に位置する独立したテクノロジーインフラストラクチャです。また、各アベイラビリティゾーンは、独立した電源および冷却システム、物理的セキュリティを擁し、大容量な光ファイバーネットワークを通じて Amazon のグローバルバックボーンネットワークに接続しています。AWS 大阪ローカルリージョンは、当初、単一のアベイラビリティゾーンのみを提供し、データセンター間をこれまで以上に地理的に離すことで、特定のアプリケーションのニーズに対応します。 AWS 大阪ローカルリージョンは、通常の AWS リージョンと同じように、他の AWS リージョンから独立し、 AWS リージョン内に独立した API エンドポイントを有します。大阪ローカルリージョンは、東京から 400 キロメートル離れた地点に位置しているため、 AWS 東京リージョンからさらに離れた場所に、拡張可能なデータセンターが必要なお客様に適しています。 IT 資産に対する追加の対策として、国内に地域的な多様性を重要視するお客さまは […]

Read More

Amazon Redshiftを使用した高性能ETL処理のベストプラクティス Top 8

ETL(Extract、Transform、Load)プロセスを使用すると、ソース・システムからデータ・ウェアハウスにデータをロードできます。 これは、通常、バッチまたはほぼリアルタイムのインジェスト(挿入)プロセスとして実行され、データウェアハウスを最新の状態に保ち、エンドユーザーに最新の分析データを提供します。 Amazon Redshiftは、高速でペタバイト規模のデータウェアハウスであり、データ駆動型の意思決定を簡単に行うことができます。 Amazon Redshiftを使用すると、標準的なSQLを使用して、費用対効果の高い方法で大きなデータを洞察することができます。 StarおよびSnowflakeスキーマから、分析クエリを実行するための単純化された正規化されていないテーブルまで、あらゆるタイプのデータモデルを使用した分析が可能です。 堅牢なETLプラットフォームを操作し、Amazon Redshiftにデータをタイムリーに配信するには、Amazon Redshiftのアーキテクチャを考慮してETLプロセスを設計します。 従来のデータウェアハウスからAmazon Redshiftに移行する場合、リフト・アンド・シフト方式を採用することが魅力的ですが、結果としてパフォーマンスとスケールの問題が長期的に発生する可能性があります。 この記事では、ETLプロセスにおける最適かつ一貫した実行時間を確保するためのベスト・プラクティスを下記にご紹介します。 複数の均等なサイズのファイルからデータの COPY Workload Management (WLM) を用いたETL実行時間の改善 定期的なテーブルのメンテナンスの実施 単一のトランザクションで複数ステップの実行 データの一括読み込み UNLOADを利用した大きな結果セットの抽出 アドホックETL処理に Amazon Redshift Spectrumを使用 診断クエリを使用して日常的なETLヘルスの監視 1. 複数の均等なサイズのファイルからデータの COPY Amazon RedshiftはMPP(大規模並列処理)データベースで、すべての計算ノードがデータの取り込み作業を分割して並列化します。 各ノードはさらにスライスに細分され、各スライスは1つ以上の専用コアを有し、処理能力を等しく分割します。 ノードあたりのスライス数は、クラスタのノードタイプによって異なります。 たとえば、各DS2.XLARGE計算ノードには2つのスライスがありますが、各DS2.8XLARGE計算ノードには16のスライスがあります。 Amazon Redshiftにデータを読み込むときは、各スライスに同じ量の作業をさせることを目指すべきです。 1つの大きなファイルまたは不均一なサイズに分割されたファイルからデータをロードすると、一部のスライスは他のスライスよりも多くの仕事をする必要があります。 その結果、プロセスは最も遅い、または最も負荷の高いスライスと同じ速度で実行されます。 以下の例では、1つの大きなファイルが2ノードのクラスタにロードされ、ノード「Compute-0」のうちの1つだけがすべてのデータ処理を実行します。 データファイルを分割する際には、圧縮後のサイズがほぼ同じ(1 MB〜1 GB)であることを確認してください。 ファイル数は、クラスタ内のスライス数の倍数にする必要があります。 また、gzip、lzop、またはbzip2を使用してロードファイルを個別に圧縮し、大規模なデータセットを効率的にロードすることを強くお勧めします。 1つのテーブルに複数のファイルをロードする場合は、複数のCOPYコマンドではなく、テーブルに対して1つのCOPYコマンドを使用します。 Amazon Redshiftはデータの取り込みを自動的に並列化します。 1つのCOPYコマンドを使用してデータをテーブルにバルクロードすると、クラスタリソースの最適な使用と可能な限り高いスループットが可能となります。 2. Workload Management (WLM) を用いたETL実行時間の改善 […]

Read More

東京リージョンで Amazon Aurora with PostgreSQL Compatibility をご利用可能に

Amazon Aurora PostgreSQL-compatible edition が、アジアパシフィック (東京) でも利用可能となりました。これにより、データベースの構築、可用性、スケーラビリティを確保するための選択肢が広がります。 Amazon Aurora は、ハイエンドな商用データベースのパフォーマンスと可用性、オープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Amazon Aurora は、一般的な PostgreSQL データベースと比べてパフォーマンスが最大 3 倍であり、さらにより高いスケーラビリティ、耐用性、およびセキュリティを備えています。詳しくは、Amazon Aurora の製品ページをご覧ください。リージョンごとのサポート状況については、製品およびサービス一覧をご覧ください。 Recent Updates 2018年に入り、RDS for PostgreSQL からの移行に関して機能が追加されています。 Amazon RDS for PostgreSQL のリードレプリカとして Aurora PostgreSQL レプリカの作成:これにより、スナップショットからの移行に比べてよりダウンタイムの短い移行が実現できます。 暗号化されたスナップショットからの移行:これにより暗号化された状態を維持したまま、 RDS for PostgreSQL インスタンスからの移行が可能です。 移行について 既存のデータベースからの移行については、その運用環境に基づいて、いくつかの選択肢が考えられます。RDS for PostgreSQL をご利用の場合、AWS が提供する機能を利用して移行できます。上記のアップデートでも紹介しましたが、具体的には以下の通りです。 Aurora レプリカを利用した RDS for PostgreSQL からのレプリケーション RDS for PostgreSQL スナップショットからの移行 注意点として、上記の2つの機能を利用するためには、現在のところ RDS for […]

Read More

ホワイトペーパー「日本におけるプライバシーに関する考慮事項に照らした AWSの利用」の公開

2017年5月30日、昨今の IT 技術の飛躍的に進歩に伴い、様々な個人情報の利活用の現状を踏まえ、改正個人情報保護法が全面施行されました。個人情報の取り扱いに関する義務が明確になりましたが、一方でクラウドをご利用する上で配慮すべき点が増え、考慮されているお客様もいらっしゃるかと思います。そのようなお客様の声にお答えするために、お客様が自身のクラウド利用を検討していく際の参考資料として「日本におけるプライバシーに関する考慮事項に照らした AWS の利用」(ホワイトペーパー)を準備し、コンプライアンスのリソースページにて公開しました。本ホワイトペーパーは、今回の改正個人情報保護法に沿った内容となっており、お客様がご自身の IT インフラストラクチャを AWS へ移行する際の主な検討事項となる以下の点について解説しています。   • コンテンツのセキュリティをどのように担保していくのか? • コンテンツはどこに保存されるのか? • コンテンツにアクセスできるのは誰か? • どのような法令がコンテンツに適用され、これらを遵守するには何が必要か?   上記のようなお客様がクラウドのセキュリティやプライバシーについて検討いただく際に、最も重要となるのが「責任共有モデル」についての理解です。AWS はクラウドサービスにおけるインフラストラクチャ自体のセキュリティについて責任を持ちます。一方で、お客様はサービス利用に際して法令を遵守し、併せて当該クラウド環境の上に構築するサービス、オプションの構成やデータ保護のための追加の構成等によりご自身のコンテンツについてのセキュリティを確保するという責任を持つことになります。AWS ではこのようにお客様と AWS の2者でシステム全体の統制やセキュリティを担保していくモデルを「責任共有モデル」と呼んでいます。詳しくは本ホワイトペーパーの「クラウドセキュリティの管理に対する AWS 責任共有の考え方」をご参照ください。   また、AWS のサービスをご利用いただく際に、お客様のコンテンツの所有権と管理権はお客様に保有することになり、AWS にコンテンツの所有権と管理権が移るようなことはありません。したがって、コンテンツの性質やセキュリティ要件に応じたセキュリティの強度レベルを決定できるのはお客様自身となります。お客様が AWS サービスをどのように構成し、アクセス権をどのように付与し、どのリージョンを使用するか等の個別な設定については、お客様の判断と責任の下でコントロールしていただくことになります。(どのような場合に AWS がお客様のコンテンツにアクセスをする可能性があるかにつきましては、「カスタマーコンテンツにアクセスできるのは誰か?」をご参照ください。)   一方、AWS のクラウドサービスのインフラストラクチャーに関するセキュリティを確保するのは AWS の責任です。例えば、AWS はファシリティ、物理セキュリティ、物理インフラ、ネットワークインフラ、仮想インフラの管理につき責任を負います。セキュリティは、AWS における最優先事項です。セキュリティに対する継続的な投資を行い、セキュリティ専門部隊を設置しています。併せて、お客様が安心して AWS のサービスをご利用いただけるよう幅広いセキュリティ機能、ツールを備え、お客様に提供しています。AWS のサービスとインフラストラクチャーは、セキュリティコントロールの設計及び運用についての有効性を証明する、数多くの認定・認証・監査に関連して第三者からの評価を受けており、機密保持契約に基づき AWS Artifact を通じてオンラインにて直接確認いただくことが可能です。(AWS Service Organization Control(SOC) 1、SOC2、PCI DSS7 コンプライアンスレポート等。ISO27001, ISO27017, ISO27018, […]

Read More

ポート443でTLS認証を使ったMQTT: なぜ便利で、どのように動くのか

AWS IoT Coreサービスで、ポート443でTLSクライアント認証を使用してMQTTを使用してデバイスを接続できるようになりました。この機能を利用してどのようにデバイスを接続するのかを知るには次をお読みください、デバイス接続方法についてを知るには最後のセクションをお読みください。 443, 8883 -違い TCP接続は通常、IPアドレスとポート番号の組み合わせの関連付けがなされています。そのために、アプリケーションが他のサードパーティのアプリケーションと通信できるようにするためには、使用するポート番号の問い合わせが発生します。これを解決するために Internet Assigned Numbers Authority(IANA)は 、組織に登録されているTCPとUDPの様々なメッセージプロトコルに対するマッピングを維持管理しています。これは標準的なリストではありませんが、広く採用されています。データベースのクイック検索では、ポート443はHTTP over TLSとして登録済みのポートであり、8883はMQTT over TLSとして登録済みのポートです。 AWS IoT Coreはこれらの規格を可能な限り遵守していますが、これを逸脱するシナリオがあることをお客様から学びました。

Read More

【開催報告】AWS Media Services ローンチセミナー

こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 1月23日にre:Invent 2017で発表されたAWS Media Servicesのラウンチセミナーを行いましたので、その資料公開とともに内容をブログでお届けします。 AWS Media Servicesは、クラウド上で動画ワークフローを構築可能なフルマネージドのメディアサービス群となります。 このサービスを使用して、信頼性の高い、ブロードキャスト品質の動画ワークフローをクラウド上で簡単に構築できます。AWS Media Servicesを使用すると、メディアおよびエンターテイメント企業、エンタープライズ、スタートアップ企業、政府機関のいずれを問わず、視聴者にプロフェッショナル品質のメディア環境を簡単に提供できます。従来のデータセンターで時間、労力、費用を費やして特殊なビデオ機器を運用する必要はありません。これらのオンデマンドで伸縮自在なサービスにより、イノベーションを加速させ、動画テクノロジーのさまざまな変化に迅速に対応できます。 Amazon CloudFront、AWS CloudFormation、Amazon CloudWatch などの AWS の補完的なサービスと、セキュリティ、管理、本番環境向けサードパーティアプリケーションとの統合により、ライブ動画およびオンデマンド動画コンテンツの処理と配信のためのツール一式が提供されます。 AWS Media Servicesは全部で5個のサービスから構成されます。 AWS Elemental MediaConvert AWS Elemental MediaLive AWS Elemental MediaPackage AWS Elemental MediaStore AWS Elemental MediaTailor それぞれのサービスの紹介は是非、上記リンクをクリックしてご確認ください。 セミナーではまず、私の方からAWSのロードマップに見るCloudFrontの重要性や、分散型と集中型におけるアーキテクチャの違い、AWSメディアワークロードの事例についてお話をさせていただきました。 続いて、AWS Elementalプロダクト マネージメント ディレクターのリオネル・ブランギエ から 本題のAWS Media Services 紹介セッションを同時通訳でお届けしました。 Aws elemental mediaservices_japan_sharever from Kameda Harunobu その後、ソリューションアーキテクト M&E の安司 仁より、「初心者でも簡単 AMSデモンストレーション」としてLive配信を20分で構築可能なデモを行いました。 20180123 20分でlive配信aws […]

Read More

Amazon Aurora: MySQL 5.7互換をリリース

Amazon AuroraのMySQL 5.7互換版が皆様にご利用頂けるようになりました。JSONサポート、空間インデックス、generated columnsなどをご利用頂け、MySQL 5.7より最大5倍高速です。 Amazon Auroraの空間インデックスの作成は、MySQL 5.7よりも20倍以上の書き込みパフォーマンスと10倍以上の読み込みパフォーマンスとなっています。この機能がどのように実装されているかについては、AWSデータベースブログをご覧ください。またAmazon Auroraのドキュメントもご参照下さい。 Aurora with MySQL compatibilityがご利用頂ける13リージョン(US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Montreal), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai))全てでご利用頂けます。 ハイエンドな商用データベースのパフォーマンスと可用性を、オープンソースデータベースのシンプルさとコスト効率と組み合わせたAmazon Aurora (MySQLとPostgreSQL互換のリレーショナルデータベース)の詳細については、Amazon Auroraの製品ページをご覧ください。 CLIを用いた際のエンジンバージョンの指定方法や、スナップショットを利用したアップグレードなどAurora MySQL5.7互換に関する詳細な情報はドキュメントやフォーラムアナウンスをご覧ください。 […]

Read More

クイックスタートによるAWSクラウドへのSAP NetWeaverの展開

Somckit Khemmanivanhは、Amazon Web Services(AWS)のSAP Solutions Architectです。 現在、AWSクラウド上の244 GiBから4 TiB RAMのスケールアップ、あるいは最大50 TiB RAMのスケールアウトで認定されているSAP HANAシステムの自動的なプロビジョニングとインストールのために、AWS SAP HANAクイックスタートは利用されていますか?FAST移行プログラムの移行戦略の一環としてSAP HANAクイックスタートを使われているかもしれません。もし、SAP HANAシステムとして1つ、あるいは複数のSAPアプリケーションをプロビジョニング、インストールしたいとき、これらと同様なシナリオを必要としていないでしょうか。少し前までは、独自のAWS CloudFormationテンプレートを作成するか、自動的にAmazon Elastic Compute Cloud(Amazon EC2) インスタンスをプロビジョニングして、SAPシステムをインストールするカスタムスクリプトを開発する必要がありました。今回のSAP NetWeaverクイックスタートにより、これらの面倒な仕組みづくりや手作業を排除できます。お客様に必要なすべてのこれらのタスクが実行されるので、お客様は他のビジネスクリティカルな活動に集中することができます。 SAP NetWeaverは、SAP アプリケーションを開発・実行するための一連のテクノロジーを提供する基盤コンポーネントです。SAP Business Suite、SAP S/4HANA、SAP Business Warehouse(SAP BW)、および SAP BW/4HANAなどのSAP製品やアプリケーションは、SAP NetWeaverに依存しています。クイックスタートは、AWSベストプラクティスに従い、AWS上に主要なテクノロジーをデプロイするためのAWS CloudFormationテンプレートを使用して、リファレンスの展開を自動化します。このクイックスタートは、Advanced Business Application Programming(ABAP)用のSAP NetWeaver Application Server(AS)を展開し、SAP HANAデータベース用のABAPベースのアプリケーション開発をサポートします。SAP HANAクイックスタートと統合されており、引き続き個別に展開することもできます。 このクイックスタートは、AWSクラウド環境にSAPアプリケーションサーバを展開し、これらのサーバをSAP HANAシステムと接続して統合します。その結果、完全にプロビジョニングされ、自動的にインストールされたSAPシステムがSAP HANA上で実行されます。 以下は、SAP NetWeaverクイックスタートが展開するアーキテクチャの概要です。 このクイックスタートでは、お客様のAWSアカウントにおける仮想プライベートクラウド(VPC)内に、SAPアプリケーション層、SAP HANAデータベース層、リモートデスクトッププロトコル(RDP)、および踏み台ホストを展開します。この展開には、SAPシステムの機能を提供するプライマリアプリケーションサーバ(PAS)インスタンスと、SAPアプリケーション層をスケールアウトするためのオプションであるアディショナルアプリケーションサーバ(AAS)インスタンスを含みます。 システムを異なった方法で構築したい場合は、GitHubリポジトリからAWS CloudFormationテンプレートとスクリプトをダウンロードし、お客様の固有要件に合わせてカスタマイズすることができます。 AWS上でSAP […]

Read More

オンデマンドウェビナー「見積もり作成ハンズオン」を公開しました。

こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 日々セミナーなどで皆さんにいろいろなコンテンツをお届けしていますが、その中でとても多くの再演要望をいただいているセミナーがあります。今回その「見積もり作成のハンズオン」をオンデマンドウェビナーとしてご提供することができるようになりました。お申込みをいただければ、いつでも皆さんが必要な時に視聴できるようになっています。是非こちらからお申込みください。 全部で3部構成となっています。 Part 1: Amazon EC2、Amazon RDS 等 主要サービスの費用について基本的な考え方をまとめています。   Part 2: 概算費用算出における検討事項のポイントやお支払方法についてまとめています。 クラウドは IT リソースの伸縮が自由であり、オンプレミス型の IT とは考え方が異なる部分が多くあります。見積もり作成において、そのあたりの注意点が含まれています。また日本円支払い、請求書支払いについてもまとめました。 Part 3: 実際の練習問題をもとに簡易見積もりツールを用いて、皆さんに見積もりを作成いただくハンズオン形式になっています。AWS の提供するクラウドサービスは、従量課金で費用想定が複雑だと思われるかたもいらっしゃるかもしれません。実際は、非常に簡易に概算費用の予測が可能となっています。是非お試しください。 より複雑な構成での概算費用が必要な方は、担当アカウントマネージャにお問い合わせいただくか、こちらのお問い合わせフォームまでお問い合わせください。 また、見積もりではなく、 AWS の基本的なコンセプトなどの独習をご希望される方は、弊社シニアプロダクトマーケティングマネージャー 石橋による、はじめての AWS オンデマンドウェビナーを合わせてご視聴ください。   – プロダクトマーケティング エバンジェリスト 亀田

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