Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード

AWS Database Migration Service (AWS DMS) を利用することで、様々なデータソースから商用データベースやオープンソースデータベースへとデータを移行できます。このサービスでは、Oracle Database から Oracle Database への移行といった同一のDBMS製品間での移行をサポートしています。また、Oracle Database から Amazon Aurora, Microsoft SQL Server から MySQL へといった異なるプラットフォーム間での移行もサポートしています。さらに、ストリーミングデータを Amazon S3 から Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server を含む様々な移行先へ配信することが可能です。 Amazon Kinesis Data Firehose は、AWS へストリーミングデータをロードする上で、最も簡単な方法です。ストリーミングデータのキャプチャ、変換を行い、Amazon Kinesis Data Analytics, Amazon S3, Amazon Redshift, Amazon Elasticsearch Service へロードできます。Firehose を利用することで、すでに利用しているビジネスインテリジェンスツールやダッシュボードを使い、ニアリアルタイム分析が可能となります。Firehose はお客様が送信するデータのスループットに合わせて自動的にスケールするフルマネージドサービスで、継続した運用管理を必要としません。Firehose は、ロード前にデータをまとめ、圧縮し、暗号化することで、ロード先のストレージで必要な容量を最小化したり、セキュリティを向上させたりすることができます。 AWS DMS […]

Read More

SAP HANA Dynamic Tiering – AWSクラウド上で検証済み、およびサポート開始

この記事は、Amazon Web Services(AWS)でSAP Solutions Architectを務めるSomckit KhemmanivanhとRahul Kabraによるものです。 私たちは、パートナーであるSAP社と緊密に連携しており、AWSクラウド上でのSAP HANA Dynamic Tieringを検証してきました。AWSがSAP HANA Dynamic Tieringのプラットフォームとしてサポートされたことを発表でき、非常に嬉しく思います。SAP HANA Dynamic Tiering Product Managerを務めるCourtney Claussenの発表もご覧ください。ここでは、Dynamic TieringとAWS上での活用におけるメリットについて詳しく説明します。 SAP HANA Dynamic Tieringにより、SAP HANAデータベースは、Dynamic Tieringのサービス(esserver process)を稼働している別の専用ホスト上にウォームデータを格納できるようになります。Dynamic Tieringを使用すると、ウォームデータを格納して処理するためのマルチストアおよび拡張テーブルを作成できます。 Dynamic Tieringには以下の3つの大きなメリットがあります: 頻繁にアクセスされない古いデータを統合ディスク層にオフロードできます。 優れたパフォーマンスでディスク層のデータにアクセスできます。 SAP HANAシステムの総所有コスト(TCO)を大幅に削減します。 Courtney Claussenが、少し前にDynamic Tieringの非常に魅力的なユースケースについてのブログ記事を公開しています。電力・公益事業のお客様の請求処理の一環として、500万レコードが処理されました。これらのレコードは、SAP HANAだけで実行しているときには53分で処理できました。このベースラインが確立された後、500万レコードの25%をDynamic Tieringのマルチストアテーブルに移行しました。その結果、テーブル行の75%がSAP HANAに配置され、残り25%がDynamic Tieringに配置されます。請求処理を再度繰り返した結果、合計実行時間は58分、つまり実行時間はわずか10%の低下に留まっており、これは大幅な低コスト化をしつつ、ほぼ同等の性能を実現できることを意味します。 これらの驚くべき結果とお客様からのフィードバックが、SAP社と緊密に連携してAWSクラウド上のSAP HANA Dynamic Tieringを検証する動機になり、現在、AWSのお客様はこのサービスのパフォーマンス、コスト削減、および今後のイノベーションの恩恵を受けることができます。 AWSでは、認定されたSAP HANAシステム(244 GiB RAMから最大4 TiB RAMまでの範囲)を小規模から始め、要件の変更に応じて規模を拡大することができます。同様に、Dynamic Tieringでも、ニーズ、ワークロード、ユーザー、およびトラフィックパターンの変更に応じて、小規模から始めて容量を追加していくことができます。例えば、4 TiBのSAP HANAシステムを使用している場合、私たちが検証済みの488 […]

Read More

AWS FinTech リファレンス・アーキテクチャー日本版の公開について

アマゾン ウェブ サービス(以下 AWS )は、日本の金融機関の皆様が参照される FISCのガイドライン や PCI DSS, ISO27001, ISO27017 などの様々な統制やセキュリティ基準への対応をしてきました。現在ではグローバルに世界各国の金融機関やFinTech のお客様にAWS のサービスをご活用いただいております。この度そうした知見や実績を活かし、日本の金融機関やFinTechのお客様が主に参照される各種のガイドラインの主要な要求事項と技術的検討が必要な項目を網羅的に確認し、「AWS FinTech リファレンス・アーキテクチャー 日本版」を作成し、本日AWSコンプライアンスWEBサイトの日本のFinTech向けのページにて公開しました。お客様は、このアーキテクチャーを活用することにより、 AWS 上に FinTech サービスの環境の構築を迅速に実現する、あるいは、既存環境に関連したセキュリティや統制についての確認を行うことが可能となります。 今回の取り組みは「AWS FinTech リファレンス・アーキテクチャー日本版のホワイトペーパー」、「AWS FinTech リファレンス・ガイド 日本版」、「AWS FinTech リファレンス・テンプレート 日本版」の3つの要素で構成されています。

Read More

Amazon RDSのリードレプリカがMulti-AZ配置をサポートしました

本日より、Amazon RDS for MySQL, MariaDBのリードレプリカがMulti-AZ配置をサポートしました。Multi-AZ配置を設定したリードレプリカを利用することによって、データベースエンジンのアップグレードプロセスの簡素化やディザスタリカバリを見据えた環境を構築することが可能になります。 Amazon RDSのリードレプリカは1つ以上の読み込み専用のデータベースインスタンスをマスターインスタンスと同一のAWSリージョン、もしくは異なるAWSリージョンに作成することが出来ます。ソースデータベースで行われた変更は非同期でリードレプリカへ伝播されます。読み込みが多いワークロードに対するスケーラビリティに加えて、リードレプリカを必要に応じて単一のデータベースインスタンスへ昇格させることも可能です。 Amazon RDS Multi-AZ配置は1つのAWSリージョン内での可用性を向上させます。Multi-AZ環境では、異なるアベイラビリティゾーン(AZ)に存在するスタンバイインスタンスに対してデータが同期的に伝播されます。インフラストラクチャの障害が発生した場合、Amazon RDSはスタンバイインスタンスへ自動的にフェイルオーバーを行い、アプリケーションへの影響を最小限に抑えます。 本番データベースへのディザスタリカバリ(DR)対応として、Multi-AZ配置のリードレプリカをお使いいただけるようになりました。よくデザインされ、テストされたDRプランは災害が発生した後の事業継続性に対して非常に重要な要素になります。ソースデータベースとは別のリージョンにある、リードレプリカをスタンバイ・データベースとして使用し、万が一リージョン障害が発生した場合に新しい本番データベースへ昇格することが可能です。 また、データベースエンジンのアップグレードプロセスにMulti-AZ配置のリードレプリカを利用可能です。本番データベースにリードレプリカを作成し、新しいデータベースエンジンバージョンへ更新します。アップグレードが完了した後に、アプリケーションを一時的に停止し、リードレプリカを単一のデータベースインスタンスとして昇格させます。そして、アプリケーションの接続先を変更します。既に昇格したデータベースインスタンスはMulti-AZ配置になっているため、追加の作業は必要ありません。 更に詳細な情報はこちらをご覧ください。リードレプリカでMulti-AZ配置を行う際に注意していただきたいパラメータについて記載しています。   翻訳は星野が担当しました。(原文はこちら)

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

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

あけましておめでとうございます。パートナーソリューションアーキテクトの相澤です。2018年1月のAWS Black Belt オンラインセミナーの配信についてご案内させて頂きます。 昨年度開催された、re:invent 2017の振り返りは、みなさまお済みでしょうか? 多くの新サービス、新機能が発表されましたが、2018年1月のBlackBeltでは、その振り返りをしていきたいと思います。 1月16日(火) 12:00~13:00 Machine Learning / Database 1月17日(水) 18:00~19:00 Compute、Container / Network 1月23日(火) 12:00~13:00 IoT / DevOps 1月24日(水) 18:00~19:00 Security / Other お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。        

Read More

Amazon Auroraを使用したMagento Content Servicesの構築をAWS Quick Startで加速させる

AWS Quick Startでは、2015年9月にオープンソースのコンテンツ管理システムであるMagentoを初めてリリースしました。最初のリリース以来、このQuick Startは常にお客様に最も人気のあるQuick Startのトップ10に入っています。 2017年10月、AWS Quick Start for Magentoのアップデートをリリースしました。Amazon Aurora MySQL-compatible editionのサポートが追加されました。また、Magentoのバージョンを2.1.2にアップデートしました。更新されたMagentoのQuick Startを利用することで、最新のMagentoバージョンでAuroraのパフォーマンスとスケーラビリティを使用して、コンテンツシステムの構築を迅速に行うことが出来ます。 数年前にAmazon Auroraの開発を開始した際に、私たちは次のような考え方を念頭に置いていました: ハイエンドの商用データベースのパフォーマンスと可用性を、オープンソースのシンプルさとコスト効率で実現 一般的なオープンソースデータベースであるMySQLとの完全な互換性を提供し、既存のアプリケーションを変更する必要がない アプリケーションの開発に専念できるように、データベースをマネージドデータベースとして提供することで管理コストを軽減 最新アプリケーションのスケーラビリティのニーズを満たすクラウドネイティブデータベースを提供 すでに何千もの顧客やパートナーが、Amazon AuroraMySQL-compatible editionを採用しています。お客様とISVパートナーは、様々なデータベースからAmazon Auroraに移行を行っています。オンプレミスデータベースからAmazon Auroraに移行されるお客様や、Amazon EC2上のMySQLまたは商用データベースからAmazon Auroraに移行を行うお客様もいらっしゃいます。 Magento on AWS with Amazon Aurora Magentoは、e-commerceウェブサイト用のオープンソースのコンテンツ管理システムです。セラーと開発者はオープンアーキテクチャ、柔軟性、拡張性(何百もの拡張機能)を評価しています。また、独自のニーズに合わせて、バックエンドのワークフローを調整できます。 Magento Community Edition(Magento CE)とMagento Enterprise Edition(Magento EE)は、我々のお客様に人気があります。多くのお客様は、Anchor Hosting、Elastera、Tenzing、Razorfish、OptarosなどのAWSパートナーを利用してMagentoをAWSでホストしています。他の企業はAWS MarketplaceからMagentoを起動しています。 Magentoを検索すると、2015年の20件から70件以上のリストが返されるようになりました。さらに、MagentoのAWS Quick Startを直接利用している企業もあります。 Amazon AuroraはMySQLと互換性があるため、MagentoのAWS Quick Startを更新するのは簡単です。新しいQuick Startでは、Magentoまたはその設定を変更する必要はありません。今使用しているコード、ツール、アプリケーションを、Amazon Auroraと既存のMySQLデータベースと併用することが可能です。 MagentoのAWS Quick Startを使用してデプロイした場合は、Amazon RDS […]

Read More

【開催報告】AWS-HUB

全国70以上の支部で構成される勉強会コミュニティを中心とした、Japan AWS User Group (JAWS-UG)の2017年納会が12月20日に行われました。インターネットで各会場を接続した「オンライン納会」は、各会場が個別に年末勉強会や忘年会を企画し、午後8時にビデオチャットで仙台、東京、金沢、名古屋、神戸、愛媛、高知、長野の全国8会場を結んで乾杯を行い、一年の労をねぎらいました。   ユーザーグループの活動のメインは勉強会ですが、今回のように各人のネットワーキングを広げる懇親会も非常に重要です。この場でコミュニティの雰囲気を感じていただき勉強会に参加されるようになったかたも多くいらっしゃいます。「AWS-HUB」とはAWSユーザーが集まって懇親を深める「パーティー」をさし、この言葉は日本のみならず、グローバルでも使われています。   東京会場のアマゾン ウェブ サービス ジャパン アルコタワーには30名を超えるメンバーと数名の社員が集まりました。AWSのノベルティープレゼントクイズなどを行い、メンバー間の懇親を深めました。             [AWS-HUB@目黒アルコタワー]             [立食形式で各テーブルで会話がはずみます(東京会場)]   午後8時前には各会場をビデオチャットツールで接続し、それぞれの会場の模様をネット越しで共有し、AWSJのコミュニティプログラム担当の沼口の発声により全員で乾杯をしました。                                           今回のオンライン納会は全国8会場、おおよそ100名のJAWS-UGメンバーをつなげて行われました。30名をこえる会場もあれば、3名のこじんまりとした会場もありました。場所と規模の違いを超えネットとディスプレイを通して各会場で経験を共有するこの方法は、全国に支部を展開するJAWS-UGのメンバーにとって容易にネットワーキングを広げる手段です。 JAWSへの参加にご興味がある方は勉強会カレンダーを是非ご確認ください。またAWS-HUBの開催情報もチェックしてみてください。 そして、来年3月、JAWS最大のイベント、JAWS DAYS 2018が五反田で開催されます。みなさんにお会いするのを楽しみにしています。 […]

Read More

kopsを使ってKubernetesクラスタをAWS上で構成

この記事では、KubernetesクラスタをAWS上で構成し運用するツールの1つであるkopsを利用すると、簡単にKubernetesを始められることをご紹介します。なお最新情報は、GitHubで公開しているAWS Workshop for Kubernetesをご覧頂き、さらに構築したクラスタを使って様々なワークショップをご自身の手で試して頂くことをお勧めします。 kopsについて Kubernetesのトップレベルプロジェクトで、Kubernetesのクラスタを構成し運用するためのツールです。また、クラスタのローリングアップデートや、アドオンもサポートしています。必要に応じて、AWS CloudFormationやTerraformのテンプレートを出力することもできるので、それを基準にカスタムして行くということも可能です。 kopsをインストール kopsは2017年12月26日時点では、macOS、Linux、Windows 10 Linux Subsystemで利用可能です。この記事ではmacOSを利用していきます。Homebrewが対応しているので以下のコマンドでインストールするのが最も簡単です: $ brew update && brew install kops SSH鍵の生成 kopsはクラスタ作成の際にSSHの公開鍵を利用します。デフォルトの配置場所は~/.ssh/id_rsa.pubとなります。ssh-keygenコマンドを利用して作成しておきます。 $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (~/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ~/.ssh/id_rsa Your […]

Read More

AWS CodePipelineとAmazon ECSを使って継続的デリバリパイプラインを設定する

この記事はAWS Senior Technical EvangelistのAbby Fullerの投稿です。 2017年12月12日に、AWSはAWS CodePipelineのターゲットとしてAmazon Elastic Container Service (ECS)をAWS Fargateも含めてサポートしたことをアナウンスしました。このサポートにより、コンテナベースのアプリケーションやマイクロサービスを継続的デリバリするパイプラインを作成するのがより簡単になりました。 コンテナ化したサービスを手動で構築しデプロイするのは、時間がかかりますしエラーを起こしがちです。自動化されたビルドとテスト機構と組み合わせた継続的デリバリは、早期にエラーを発見し時間を短縮することを助け、失敗を減らしてくれるので、アプリケーションのデプロイモデルとして一般的なものとなってきています。以前は、ECSでコンテナワークフローを自動化するには、AWS CloudFormationを使った自前のソリューションを構築する必要がありました。これからは、わずか数ステップでCodePipelineとCodeBuildをECSと連携させてワークフローを自動かすることができます。 CodePipeline、CodeBuild、そしてECSを使った典型的な継続的デリバリのワークフローは、以下のようなものです: ソースを選択する プロジェクトをビルドする コードをデプロイする GitHub上にこのワークフローのための継続的デプロイのリファレンスアーキテクチャも公開しています。 はじめてみよう 最初に、CodePipelineで新規プロジェクトを作成し、例として”demo”というプロジェクト名を設定します。 次に、コードが保管されているソースの場所を選択します。ここには、AWS CodeCommit、GitHub、またはAmazon S3が選択できます。この例では、GitHubを入力し、CodePipelineにレポジトリへのアクセス権を与えます。 次に、ビルドステップを追加します。JenkinsサーバURLやCodeBuildプロジェクトの様に既存のビルドを持ってくることもできますし、CodeBuildで新しいステップを作成することもできます。もし既存のCodeBuildのプロジェクトがなければ、以下の様に選択してCodePipelineから新しいものを作成しましょう: Build provider: AWS CodeBuild Configure your project: Create a new build project Environment image: Use an image managed by AWS CodeBuild Operating system: Ubuntu Runtime: Docker Version: aws/codebuild/docker:1.12.1 Build specification: […]

Read More