Amazon Web Services ブログ

AWS Japan

Author: AWS Japan

AWS サンフランシスコ Summit – 発表とお知らせの概要

私の同僚の多くは、本日の AWS Summit のため、サンフランシスコにいます。メインステージおよび休憩セッションで当社が発表した概要は次のとおりです。 新しいサービス Amazon DynamoDB Accelerator (DAX) – 読み込み量が多いワークロード用のメモリ内キャッシュ Amazon Redshift スペクトラム – S3 データのエクサバイト規模のインプレースクエリ AWS CodeStar – AWS でアプリケーションをすばやく開発、構築、デプロイ 新たに利用可能 EC2 F1 インスタンスと FPGA Lambda を統合した AWS X-Ray Amazon Lex PostgreSQL と互換性を持つ Amazon Aurora のプレビュー 新機能 Amazon Rekognition の更新 – イメージモデレーション Amazon Polly – スピーチマークとウィスパー DynamoDB の VPC エンドポイントのパブリックプレビュー AWS Mobile Hub […]

Read More

AWS X-Ray の更新 – Lamba 統合を含む一般提供の開始

AWS X-Ray を最初に紹介したのは AWS re:Invent での「AWS X-Ray – 分散アプリケーションの中を見てみよう (AWS X-Ray – See Inside Your Distributed Application)」というタイトルのブログ投稿でした。AWS X-Ray は Amazon EC2 インスタンス、Amazon ECS コンテナ、マイクロサービス、AWS データベースサービス、AWS メッセージングサービスをトラバースする実行として、アプリケーションに対して行われたリクエストをトレースできるようにします。これは開発および本番環境用に設計されており、シンプルな 3 層アプリケーションや何千ものマイクロサービスで形成されたアプリケーションを処理することができます。去年公開したブログでも説明しましたが、AWS X-Ray はリクエストのエンドツーエンドのトレースや、代表的なサンプルのトレースセットの記録、サービスのマップ表示、データのトレース、パフォーマンス問題やエラーの分析を行えるようにします。これにより、アプリケーションとその基盤サービスがどのように動作しているか把握することができるため、問題の根本的な原因を識別し対処することができます。詳細については、X-Ray の機能を詳しく説明した過去のブログをご覧ください。AWS X-Ray のプレビューバージョンは re:Invent でリリースし、興味を示した開発者やアーキテクトが使用できるようにご招待しました。本日より、同サービスの一般提供を開始しました。US East (Northern Virginia)、US West (Northern California)、US East (Ohio)、US West (Oregon)、Europe (Ireland)、Europe (Frankfurt)、South America (Brazil)、Asia Pacific (Tokyo)、Asia Pacific (Seoul)、Asia Pacific (Sydney)、Asia […]

Read More

5 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー 5 月の配信についてご案内させて頂きます。4 月に引き続き、5 月も AWSの基礎となるサービスを中心に開催します。AWS 認定試験の紹介や準備について、ゲーム開発者の方々向けのサービス群のご紹介といった、新しい切り口での開催を行います。 5 月の開催予定 サービスカット 5/10(水) 18:00-19:00 Amazon RDS 5/17(水) 18:00-19:00 Amazon Cognito 5/24(水) 18:00-19:00 EC2 Windows ソリューションカット 5/11(木) 12:00-13:00 AWS for Game Developers 5/23(火) 12:15-12:45 AWS認定試験準備に向けて お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

Read More

発表: Amazon Athena が暗号化されたデータのクエリのサポートを追加

昨年 11 月に、当社は毎日膨大な量のデータに安全にアクセスして調べる必要があるお客様を支援するための重要なステップとなることを期待して、サービスをマーケットに投入しました。このサービスは Amazon Athena にほかなりません。私はこれを、オブジェクトストレージのクエリにより「1 回のジャンプで背の高いクエリを飛び越える」ことを試みるマネージド型サービスであると考えています。AWS のお客様が、Amazon S3 に保存された大量のデータを簡単に分析してクエリを実行できるようにするサービスです。 Amazon Athena は、ユーザーが標準 SQL を使用して Amazon S3 のデータを簡単に分析できるようにする、サーバーレスでインタラクティブなクエリサービスです。Athena の中核となるのは、ANSI SQL のサポートによりクエリを実行する分散 SQL エンジンの Presto と、Athena が CSV、JSON、ORC、Avro、Parquet などのよく使用されるデータ形式に対応できるようにし、create table、drop table、alter table などのよく使用されるデータ定義言語 (DDL) オペレーションを追加する Apache Hive です。Athena は、構造化されたデータ形式および構造化されていないデータ形式で Amazon Simple Storage Service (S3) に保存されたデータセットへのパフォーマンスの高いクエリアクセスを可能にします。Hive 対応 DDL ステートメントと ANSI SQL ステートメントは、AWS マネジメントコンソールから、または Athena JDBC ドライバーをダウンロードして利用することで SQL […]

Read More

AWS Partner Network(APN) テクノロジーパートナー ATADATA: SAP on AWS移行時の強力な手助け

AWSパートナープログラム部門にてマイグレーション領域のグローバルプログラムリードを務めるKalpan Ravalによる記事です。 多くのエンタープライズのお客様は、AWSサービスの活用によりビジネスのイノベーションを促進し、以前よりもっと安全に環境を構築し、技術的負債を捨て、コストを削減しています。その結果、さらにお客様がAWSに移行しようとし、高度に自動化された移行作業の数が増えています。実績に基づく経験と高品質なツールを使用してリスクを軽減し、主要なワークロードの移行の実現を支援するために、お客様はますますAWS移行コンピテンシーパートナーを頼みにしていることが分かっています。 SAP環境は多くの場合に複雑であり、多くのビジネスワークフローにおいて中心的な役割を果たします。SAPワークロードのある様々なインフラストラクチャタイプによっては、さらに複雑さが増します。x86の観点からは、仮想マシンと物理マシンの両方でWindowsとLinuxのワークロードがあり、大量のCPUコアとRAMが実行されます。加えて、Oracle、SQL Server、またはSAP HANAなどのトランザクション性の高いデータベース用に数十台のディスクドライブもあります。ミッションクリティカルなSAPワークロードを移行する場合、その方法とベンダーを慎重に選択する必要があるという結論が導かれます。私たちは、SAP on AWSを評価いただくために参考となる多くのリソースを提供しています。また、AWS移行コンピテンシーパートナーのページとSAPコンピテンシーパートナーのページから、支援依頼が可能なAPNパートナーのリストをご覧ください。今日は、私たちのAPNアドバンスドテクノロジーパートナーで移行コンピテンシーを取得しているATADATA(アタデータ)について少しお話しし、同社のプラットフォームを使用してSAPワークロードをAWSに移行する方法を説明します。 大規模なSAPワークロードの移行 ATADATAには、SAPを含む大規模なエンタープライズワークロードの移行を可能にする総合的なプラットフォームとして機能する複数のエージェントレスな自動化モジュールがあります。これらのモジュールは、自動的なライブマイグレーションだけでなく、ディスカバリー、アプリケーションのマッピング、コスト予測、移動グループの作成と有効化、移行するワークロードの同期化のために、個別に、または統合製品として使用できます。総合的な移行プラットフォームであることに加えて、ソリューションセットは迅速に導入でき、完全に自己完結しており、エンタープライズ環境向けに設計されています。 自動化された移行の有効化と実行に必要な典型的なワークフロー:   ATAvisionディスカバリーモジュールによるアプリケーションの検出とマッピング ディスカバリーと計画策定は、あらゆる移行において不可欠なフェーズです。アプリケーション全体を移行、あるいは変換することを目的とするかどうかに関わらず、対象領域の地図なしではプロジェクトの効率性とタイムラインが失われるでしょう。これは、SAPの移行において非常に重要です。SAPは非常に複雑で、多くのモジュールでは、接続先はオンプレミス環境の外に広がる複雑なサプライチェーンにまたがる多数のエンドポイントにまで及び、ビジネスラインに影響を及ぼす可能性があります。これらの依存関係を把握することは、どのサーバーを一緒に移動する必要があるのか​​、そのインフラストラクチャの依存関係を理解し​​、最も影響の少なく都合のよい移行時期を知る上で非常に重要です。 ATADATAプラットフォームが持つエージェントレスのATAvisionモジュールを使用することで、移行を最適にできるようSAPの依存関係が検出されます。移行アーキテクトは、相互に依存し合うアプリケーションとサーバーが密接に結びついているかどうかを知る必要があります。ATAvisionは、この目的のために設計されており、組み込まれたインテリジェンス機能を使用してアプリケーション通信によって関連するインフラストラクチャをグループ化します。 ATAvisionディスカバリーモジュールによる移行の移動グループの作成とコスト予測 ATAvisionは、移行の移動グループとそれを組み込んだ段階計画を策定するために必要な情報を提供するよう開発されました。ATAvisionは、スプレッドシートを手動で作業し、ピボットテーブルを使用してサーバーを移動グループに結びつける移行アーキテクトもまだありますが、SAPなどのシステムで特に役立つ移動グループの自動作成ができるようになりました。 ルールを定義するだけで、ロジックが引き継がれます。自動的な移動グループテクノロジーがもたらすインテリジェンスとスピードにより、膨大な作業時間を節約し、スプレッドシートに頼っていたときの人為的ミスのリスクを軽減できます。 さらに、移行前に、クライアントおよびアプリケーションチームは、個々の移動グループごとのAWS使用量を予測したり、収集された属性の数をフィルタリングしたりすることができます。 ATAmotion移行モジュールを使用したポイント・ツー・ポイントの移行とAWSへの同期 ATAmotionはATADATAのコア製品であり、独自のマルチスレッドクローンエンジンと高度なAWS APIとの統合ポイントによって可能になる、大規模なエンタープライズワークロードを移行するという使命を持って開発された堅牢なアーキテクチャを備えています。 ATAmotionのポイント・ツー・ポイントの定義とはどういうことでしょうか?データは中間ステージやイメージライブラリー、ストレージバケットを経由せずにソースマシンからVPC内で指定されたクライアントサブネットにあるAmazon Elastic Compute Cloud(Amazon EC2)上のターゲットインスタンスに直接流れます。このアーキテクチャでは、基盤となるOSやデータベースの種類に関係なく、数多くの稼働中のSAPワークロードの移行を同時にサポートできるため、複雑なSAP環境の場合でも移行期間を数週間から数時間に短縮できる可能性があります。 ATAmotionは、Windows Serverのバージョン2003 32bitから2016まで、Red Hat Enterprise Linux、SuSE Enterprise Linux、Debian、OpenSuSE、CentOS、Oracle Linux、Amazon Linux、Fedora、Ubuntuといったすべての一般的なLinuxディストリビューションをサポートしています。あらゆるクラウド環境またはオンプレミス環境からAWS(米国) GovCloudリージョンを含むすべてのAWSリージョンへの移行、あるいはリージョン間の移行をサポートしています。移行が大陸をまたがったり低帯域幅の場合、ATAmotionはコピーの遅延または中断を監視し、データコピーを正常に完了させる最も効果的な方法を見つけます。 ATAmotionソフトウェアは、サポートされているWindows / Linuxのいずれかで実行中のデータ集約型のSAPアプリケーションを、実質的にダウンタイムなしで移行することができます。これは主に、ATAmotionはクライアントホストのCPU使用率が非常に低く、数MBのメモリしか消費しないため、このような低いリソース使用率のおかげでサービスを中断しないからです。そして、ATAmotionはすべてのファイルシステムを移行します。オペレーティングシステムとそのデータがいくつかのLVM論理ボリュームと物理ボリュームに分割されているかどうかは関係なく、固定パーティションを使用して100個のディスクに格納されている場合であっても、ツールがターゲットサーバ上に同じデバイス構造を再作成するため同じままの構成になります。 さらに、その構造に基づいてデータを移動するための適切な方法を選択するインテリジェンス機能があります。データがファイルシステムに格納されている場合、ファイルベースのコピーアルゴリズムを使用してデータがコピーされます。しかし、ファイルシステムが存在しないデータベースの一般的なシナリオであるRAWデバイスに格納されている場合は、ブロックコピーアルゴリズムを使用してデータがコピーされます。 最後に、ATAmotionには、複数の自動化された同期手法が組み込まれているため、カットオーバー前、カットオーバー中に様々なカットオーバー戦略が取れます。 SAP on AWS移行時におけるATADATAプラットフォームのメリット 単一のベンダー管理で、エンド・ツー・エンドのシームレスなAWS移行が可能になる 検証済みのAWS移行パートナーソリューションによりリスクを削減し、SAPワークロードをAWSに移行できる AWSへの移行を開始する前に既存のSAP環境を完全に把握できる 数十のSAPワークロードを同時に移行するような予定を早められる(数週間ではなく数時間で検討) レガシーなメソドロジーとテクノロジーに伴うコストの削減と人的ミスの軽減ができる AWSへの旅の一環として高度な自動化を活用できる リソース集中型のオンプレミスハードウェアを廃止できる もしあなたが既存のSAPワークロードのAWS移行を検討しているエンタープライズのお客様またはサービスプロバイダーでしたら、今すぐATADATAの自動化と明確な専門技術を活用することができます。ATADATAの詳細については、www.atadata.com/awsをご覧ください。 このブログの内容や意見は著者のものであり、第三者の製品を保証するものではありません。AWSはこの記事の内容や正確さについての責任は負いません。 […]

Read More

マネージメントコンソールからも、既存のEC2インスタンスにIAMロールを簡単にアタッチ、変更できるようになりました

AWS Identity and Access Management(IAM)ロールを利用すると、Amazon EC2上で動作するアプリケーションは一時的なセキュリティ資格を使用することにより安全に稼働することができます。また、アプリケーションが使用するAWSセキュリティ資格情報を利用者が管理する必要がないため、アプリケーションがインスタンスから安全にAPIリクエストが発行できます。先日、AWS CLI, AWS SDKを使用し、既存のEC2インスタンスにIAMロールを付加することで、アプリケーションに一時的なセキュリティ資格情報を使用できるようになりました。詳細は、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」を確認下さい。 そして今日から、EC2コンソール(マネージメント コンソール)からも、既存のEC2インスタンスにIAMロールをアタッチできるようになりました。 EC2コンソールを使用して、既存のインスタンスにアタッチされたIAMロールを置き換えることもできます。 このブログ記事では、EC2コンソールから既存のEC2インスタンスにIAMロールを割り当てる方法を示します。 EC2コンソールから、既存のEC2インスタンスにIAMロールをアタッチする EC2コンソールから既存のEC2インスタンスにIAMロールを添付するには: 1. EC2コンソールに移動します 2. ナビゲーションペインでInstancesを選択します。  3. IAMロールをアタッチするインスタンスを選択します。 IAMロールがまだアタッチされていないことを確認するには、インスタンスの[Description]タブのIAMロールの値が空であることを確認します。 4. [Actions]を選択し、[Instance Settings]を選択して、ドロップダウンリストから[IAMロールのアタッチ/置換]を選択します。 5. [Attach / Replace IAM role]ページから、添付するロール(この例ではEC2Role1を選択します)をドロップダウンリストから選択します。 注意:”Create new IAM role (新しいIAMロールの作成)”を選択することで、新しいロールを作成することもできます。 詳細については、「IAMコンソールを使用してIAMロールを作成するには」を参照してください。 6. IAMロールを選択したら、「Apply」を選択して次のステップに進みます。 私の場合、次のスクリーンショットに示すように、IAMの役割はEC2インスタンスに正常にアタッチされました。 ロールが目的のEC2インスタンスに関連付けられていることを確認するには、インスタンスの詳細ページに移動します。次のスクリーンショットのようにEC2Role1がIAMロールであることが確認できます。 この投稿に関するコメントがある方は、下記の「コメント」セクションに投稿頂きますと助かります。 ご質問やご提案がありましたら、IAMフォーラムの新しいスレッドからお問い合わせください。 – Mari 翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

Read More

Amazon AppStream 2.0でデスクトップアプリケーションのストリームをスケールする

Deepak Sury, Principal Product Manager – Amazon AppStream 2.0 デスクトップアプリケーションを書き換えることなくWebブラウザにストリーミングしたいですか?Amazon AppStream 2.0はフルマネージドの、セキュアなアプリケーションストリーミングサービスです。このサービスでなにができるかを知るためのかんたんな方法はエンドユーザーエクスペリエンスを無料で試してみることです。 この記事では、AppStream 2.0環境をスケールさせて、コストを最適化する方法について解説します。さらにセットアップとモニタリングについていくつか付け加えます。 AppStream 2.0 ワークフロー Image Builderを使用して自分のアプリケーションをAppStream 2.0にインポートします。Image BuilderでAWS Management Consoleからデスクトップエクスペリエンスに接続して、自分のアプリをインストールしてテストすることができます。そして、Image Builderのスナップショットとしてイメージを作成します。 アプリケーションをふくむイメージを作成したあと、インスタンスタイプを選択してストリーミングインスタンスのフリートを起動します。フリートのそれぞれのインスタンスは1ユーザーだけで使用され、フリートで使用されるインスタンスタイプがアプリケーションパフォーマンスによる必要と適合するようにします。最後に、フリートをスタックにアタッチしてユーザーアクセスをセットアップします。以下の図はワークフローのなかでのそれぞれのリソースの役割を示しています。 図1: AppStream 2.0のワークフローを記述 AppStream 2.0のセットアップ 使いはじめるためには、コンソールのクイックリンクからサンプルのAppStream 2.0スタックをセットアップします。このサンプルでは、スタックにds-sampleという名前を付け、サンプルイメージを選択して、stream.standard.mediumインスタンスタイプを選んでいます。セットアップしたリソースはAWSコンソールまたは、以下のようにdescribe-stacksやdescribe-fleetsを使用して確認することができます: 図2: AppStream 2.0スタックの確認 図3: AppStream 2.0フリートの確認 ストリーミング環境へのユーザーアクセスをセットアップするには、既存のSAML 2.0準拠のディレクトリを使用することができます。ユーザーは既存の認証情報を使用してログインすることができます。別のやり方として、クイックにストリーミング接続をテスト、または自分のWebサイトからストリーミングセッションをスタートするには、ストリーミングURLを作成することができます。コンソールで、Stacks、Actions、Create URLを選択するか、以下のようにcreate-streaming-urlを呼び出します: 図4: ストリーミングURLの作成 ブラウザにストリーミングURLをペーストして、表示されたアプリケーションを開くことができます。 これでサンプル環境のセットアップができましたので、スケーリングに移りましょう。 AppStream 2.0のスケーリングとコスト最適化 インスタントオンのストリーミング接続を提供するために、AppStream 2.0フリートのインスタンスは常時稼働しています。稼働中のインスタンスに課金され、それぞれの稼働中のインスタンスは同時に1ユーザーのみを受け付けます。コストを最適化するには、インスタンスの稼働台数を同時にアプリをストリーミングしたいユーザー数にあわせます。このセクションではそのための3つのオプションを紹介していきます: フリートのオートスケーリング スケジュールをベースにした固定フリート スケジュールによるフリートのオートスケーリング フリートのオートスケーリング インスタンスの稼働台数を動的に更新するには、フリートのオートスケーリングを使用することができます。この機能はフリートのサイズを自動的に最小値と最大値の間でオンデマンドにスケールさせることができます。これはコンスタントにユーザーの需要が変動し、需要に応じてフリートを自動的にスケールさせたい場合に便利です。スケーリングポリシーのセットアップと管理の方法については、Fleet Auto […]

Read More

New – AWS マネジメントツールのブログ

過去数年で AWS ブログのコレクションが拡大しました。右側のリストをご覧になれば分かるように、現在では実に幅広い様々なトピックや開発ツールに関するブログをご提供しています。また英語以外の言語でも、AWS ブログをご覧いただくことができます。コレクションに最近追加されたブログは AWS Management Tools Blog です。このブログでは AWS ツールを取り上げ、ユーザーがプロビジョン、設定、モニタリング、トラックのサポートや AWS のコスト管理、大規模なオンプレミスリソースの管理について説明しています。今後ブログで紹介予定のトピックには、機能の更新に関する技術的な詳細情報、ヒントやトリック、サンプルアプリ、CloudFormation テンプレート、ユースケースのディスカッションなども含まれています。ブログ開始当初の投稿をいくつか以下にご紹介します。 ステートマネージャーを使用して Auto Scaling グループで Amazon EC2 インスタンスを設定 (Configure Amazon EC2 Instances in an Auto Scaling Group Using State Manager) 拠点ホストを Amazon EC2 Systems Manager と置き換える (Replacing a Bastion Host with Amazon EC2 Systems Manager) パラメータストアを使用して安全に機密情報にアクセスし AWS CodeDeploy でデータを設定 (Use Parameter Store […]

Read More

Pollexy – Amazon Polly と Raspberry Pi で構築した特別なニーズをサポートする音声アシスタント

4 月は Autism Awareness month (自閉症啓発月間) です。米国では 68 人中に 1 人の子供が自閉症スペクトラム障害 (ASD) と診断されています (2014 年 CDC 調査)。 今回のブログでは AWS のシニア DevOps クラウドアーキテクトの Troy Larson が、息子の Calvin をサポートするために取り組んでいるプロジェクトについて紹介します。これまでにも、AWS がどのようにしてこれほどたくさんの様々なアイデアを出し合えるのか聞かれたことがあります。場合によっては、とても個人的な理由で大切な誰かの役に立ちたいという願いからアイデアが浮かぶこともあるのですが、この Pollexy はまさにその例です。まずは Pollexy に関する記事を読んでから、こちらの動画をご覧ください。 -Ana 背景 私はここ何年もの間、自閉症で会話の少ない 16 歳のティーンエイジャーの親であるコンピュータプログラマーとして、どうにかテクノロジーを使ってより安全で幸せかつ快適な暮らしをつくることができないかと常に模索していました。このプロジェクトのチャレンジとなる根源は、人との交流におけるすべての基本、つまりコミュニケーションです。息子の Calvin は口頭による指示には反応しますが、責任を持って発言することができません。彼のこれまでの人生において、私達が会話をしたことは一度もないのです。自分の部屋で一人で遊んでいることはできても、すべてのタスクや一連のタスクをこなすには、他の誰かが口頭で彼に促す必要があります。我が家には他にも子供がおり、家庭内で担当するその他の役割もありますから、Calvin にかかりっきりになることで家庭内の雰囲気に負の影響が出てしまうことも否めません。 事の発端 去年開催された re:Invent で Amazon Polly と Amazon Lex のことを初めて耳にしてから、すぐにこうした技術を活用してどのように息子をサポートできるか考え始めました。息子は人による口頭指示に対しては問題なく対応することができますが、デジタル音声を理解することはできるのだろうか? という疑問がありました。そこで、ある土曜日に Raspberry Pi を息子の部屋に設定し、ドアを閉め、息子に気付かれないように家族と一緒に様子をうかがってみることにしました。Raspberry Pi […]

Read More

EMRFSを利用して、別AWSアカウントからデータを安全に分析する

分析されるデータは、異なるアカウントが所有するバケットに分散されることがあります。データのセキュリティを確保するためには、適切な認証情報管理が必要です。これは、さまざまな部門の異なるAmazon S3バケットにデータを格納している大企業にとって特に当てはまります。例えば、顧客サービス部門は、研究部門が所有するデータにアクセスする必要があるかもしれませんが、研究部門はそのアクセスを安全な方法で提供する必要があります。 データを保護するこの側面は非常に複雑になる可能性があります。 Amazon EMRは、統合メカニズムを使用して、S3に格納されたデータにアクセスするためのユーザー認証情報を提供します。 EMR上でアプリケーション(Hive、Sparkなど)を使用してS3バケットとの間でファイルを読み書きする場合、S3 API呼び出しには認証するための適切な認証情報で署名する必要があります。 通常、これらの認証情報は、クラスターの起動時に指定するEC2インスタンスプロファイルによって提供されます。そのオブジェクトが異なる認証情報セットを必要とするため、EC2インスタンスプロファイルの認証情報がS3オブジェクトにアクセスするのに十分でない場合はどうなるでしょうか? このポストは、カスタム認証プロバイダを使用して、EMRFSのデフォルトの認証プロバイダがアクセスできないS3オブジェクトにアクセスする方法を示しています。

Read More