Amazon Web Services ブログ

Tag: EC2

【開催報告】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

新サービス License Manager – ソフトウェアライセンスの管理とライセンスルールの保全

BYOL(Bring Your Own License)を使用してAWSクラウドで商用ライセンスソフトウェアを使用する場合、不必要なライセンス調達を避けつつ、ライセンス条項の範囲内に収まるように展開を管理する必要があります。必要に応じてオンデマンドでインスタンスを起動したい場合、これは難しい課題です。 新サービス “AWS License Manager” 2018年11月28日、AWS License Managerをローンチしました。このサービスはライセンスルールを定義して、その中にエンタープライズ契約やライセンスされたソフトウェアの使用に適用されるその他の条件を考慮に入れるよう設定することができます。そして、定義したルールは展開メカニズム(ゴールデンAMIまたは起動テンプレート)に関連付けることができます。ルールが適用され起動されたEC2インスタンスは自動的に追跡されます。 また、1つまたは複数のAWSアカウントで使用状況を検出し、AWS管理コンソールからすべての使用状況を追跡することもできます。 それでは簡単に機能を見ていきましょう。ここでは、エンタープライズデータベース用のvCPUライセンスを100持っていると仮定します。 最初のステップは、1つ以上のライセンス設定を定義することです。 ライセンスマネージャコンソールを開き、[Create license configuration]をクリックして開始します: 構成の名前と説明を入力し、ライセンスがvCPUに基づいており(最大100に制限されています)、ライセンス数を限定強制したい事が示されます(Enforce license limit チェックボックスをオン): また、新たなライセンスルールを作成することもできます。 ルールは、EC2の構成に対するライセンスの適用可否を制御します。 vCPUの最小数や最大数、EC2テナントタイプ (共有、専有インスタンス、Dedicated Host) を指定できます。 例えば 4~64のvCPUと共有テナントを指定するルールは次のようになります: ルールが正しく定義されていることを確認し、Submitをクリックして次に進みます。 これで、ライセンスルールは準備が整いました。この画面ではルールの一覧が表示されており、私が作成したものと、他の人が作成したものも見る事が出来ます: ライセンスルールを作成したら、ルールを選択して[Actions]メニューの[Associate AMI]をクリックしてAMIと関連付けることができます。 1つ以上のAMIを選択し[Associate]をクリックします: 全体的なライセンスの使用状況を一目で確認できます(これは、複数のアカウントとAWS Organizationsと連携して機能するセントラルダッシュボード画面です): [Settings]をクリックして自分のAWS Organizationsアカウントにリンクし、クロスアカウントインベントリ検索を設定してライセンスの使用制限を逸脱したとき、SNSアラートを受信するように設定することも出来ます: その他 ここではAWS License Managerについてその他のいくつか知っておくべきことについて触れます: サポートされるライセンスタイプ – AWS License ManagerはvCPU、物理コア、物理ソケットをベースとしたライセンスをサポートします。特定のソフトウェアベンダーに紐づくものではありません。 クロスアカウントの使用管理 – AWS License Managerは、AWS Organizationsと組み合わせて使用する事が可能です。 マスターアカウントに署名した全てのアカウントでリンクし、組織全体でライセンス設定を共有することができます。 ダッシュボードを使用して、組織全体のライセンス使用状況を確認することができます。 […]

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

新インスタンス- NVIDIA Tesla V100 GPUを最大8個搭載したAmazon EC2インスタンス P3

私たちは2006年に最初のm1.smallを発表した後も、お客様のご要望に応じて、そして常に進歩している最先端の技術を利用可能にするために、コンピュート能力、バースト可能な性能、メモリサイズ、ローカルストレージ、アクセラレータなどインスタンスを強化し続けています。 新しいP3インスタンス 本日、次世代のGPUを搭載したEC2インスタンスを4リージョンで公開しました。NVIDIA Tesla V100 GPUを最大8個搭載したP3インスタンスは、コンピュートインテンシブな機械学習、深層学習、流体計算、金融計算、地震解析、分子計算、ゲノム処理を想定して設計しました。 P3インスタンスは、最大2.7GHzで動作するIntel Xeon E5-2686v4プロセッサを搭載し、3種類のサイズを用意しています(VPCのみ、EBSのみ) Model NVIDIA Tesla V100 GPUs GPU Memory NVIDIA NVLink vCPUs Main Memory Network Bandwidth EBS Bandwidth p3.2xlarge 1 16 GiB n/a 8 61 GiB Up to 10 Gbps 1.5 Gbps p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps p3.16xlarge 8 128 […]

Read More

Amazon EC2 スポットインスタンスを利用した Amazon ECSクラスターの起動

この記事は気前よく次の方から寄贈されました。 Chad Schmutzer Solutions Architect Shawn O’Connor Solutions Architect   本日、Amazon EC2 Container Service(Amazon ECS)が、ECSコンソール上から直接 Amazon EC2 Spot Instances上に ECSクラスターを起動させる機能をサポートする事を発表しました。 スポットインスタンスを利用すると、Amazon EC2の余剰コンピュートキャパシティに入札することが出来ます。スポットインスタンスは通常、オンデマンドインスタンスよりも50-90%安い価格です。スポットインスタンス上でECSクラスターを起動することで、既存のコンテナ化されたワークロードの実行コストを削減したり、同じ予算を維持しながら、コンピュートキャパシティを2倍から10倍に増やすことが可能です。もしくは、その両方を実現することもできます! スポットインスタンスを利用する場合、インスタンス時間あたりに支払う価格を指定します。現在のスポットプライスを上回る価格で入札している間、スポットインスタンスは起動します。スポットプライスの上昇によりインスタンスが回収された場合、インスタンスが実行された分の時間は請求されません。 ECSコンソールはスポットインスタンスをデプロイするために、 Spot Fleetを利用します。Spot Fleetは、利用者にとって最も良い価格となる様にスポットインスタンスを起動し、コンテナ化したアプリケーションの為にリクエストしたターゲットキャパシティ(インスタンスやvCPUの数で表現される)をデプロイしようします。スポットプライスや、空き容量の変化によってスポットインスタンスが回収された場合、Spot Fleetはターゲットキャパシティを維持しようとします。 コンテナはSpot Fleetが大きくなる多様なリソースプールに適してします。Spot Fleetを利用すると複数のスポットインスタンスプール(インスタンスタイプとアベイラビリティゾーンの組み合わせ)に渡ってキャパシティをプロビジョニング出来き、アプリケーションの可用性を向上させ、時間経過と共に運用コストを削減できます。ECSが提供する拡張性と柔軟性を備えたコンテナ配置システムとSpot Fleetとの組み合わせはコンテナ化されたワークロードを効率的にデプロイし、わずかなコストであらゆる規模のクラスタを容易に管理できます。 従来は、スポットインスタン上へのECSクラスタのデプロイは手動で行われてました。この記事では、ECSコンソール上からのSpot Fleetとの新しいインテグレーションによって、高い可用性とスケーラビリティをどの様に実現し、コンテナ化したワークロードをどの様にコストを削減するのかを紹介します。また、AWS CloudFormationを利用し、スポットインスタンス上にECSクラスターを構築する方法も紹介します。   スポットインスタンスで実行するECSクラスタの作成 AWS マネージメントコンソールを利用してECSクラスタを作成することが可能です。 Amazon ECSコンソールを開きます。 https://console.aws.amazon.com/ecs/ ナビゲーションパネル上でClustersを選択します。 Clustersページでは、Create Clusterを選択します。 Cluster nameに名前を入力します。 インスタンス設定では、プロビジョニングモデルとしてSpotを選択します。 配置戦略の選択 2つの利用可能なSpet Fleet配置戦略はDiversified戦略かLower price戦略です。 Spot Fleetで選択した配置戦略は、利用可能なスポットインスタンスプールからSpot Fleetをどの様に満たすかを決定します。diversified戦略を使用すると、スポットインスタンスは全てのプールにわたって分散されます。lowest price戦略を選択した場合、リクエストで指定された最低価格のプールから取得されます。 […]

Read More