Amazon Web Services ブログ

PostgreSQL コミュニティによるアップデートに追従し、PostgreSQL のマイナーバージョンである 9.6.6, 9.5.10, 9.4.15, 9.3.20 が Amazon RDS for PostgreSQL でサポートされました。このリリースでは、PostgreSQLの3つのセキュリティ上の脆弱性が修正され、追加のバグ修正と改善が行われています。 このアップデートでは、Oracle Database で利用される関数、パッケージの一部を実装した Extension “orafce” と、プレフィックスマッチングを提供する Extension “prefix” のサポートがバージョン 9.6.6 に含まれています。 マネジメントコンソールを使い数クリックで新たな RDS for PostgreSQL を作成するか、既存のインスタンスをワンクリックでアップグレードすることで、新しいバージョンを利用できます。アップグレードする場合、短いダウンタイムが発生することにご注意ください。データベースインスタンスをアップグレードするにあたっての詳細は、 Amazon RDS ユーザーガイドをご覧ください。 Amazon RDS for PostgreSQL は、クラウドで簡単に PostgreSQL を設定、運用、スケール可能です。それぞれのリージョンでご利用いただけるかどうかは、Amazon RDS for PostgreSQL の料金ページをご覧ください。 翻訳は江川が担当しました。原文はこちらです。

こんにちは、スタートアップ担当SAマネージャーの篠原英治(@shinodogg)です。 AWS Startup Tech CommunityはAWSをご利用中のStartup企業で働く技術者の皆さまにお集まりいただいているコミュニティですが、先日、11回目のMeetupをAmazon目黒オフィスで開催しました。カジュアルな雰囲気の中でも、ココでしか聞けないような実践的なやりとりが行われる非常に良い学びの場となりました。 – Voicyを支える技術 : Voicy 窪田 雄司さん Voicyを支える技術 from YujiKubota1 急成長中の注目スタートアップであるVoicyのCTO窪田さんに、Voicyで活用している技術をご紹介いただきました。 AWSのベーシックなサービスに加えて、Amazon CognitoやAmazon Mobile Analyticsといったマネージドサービスを適材適所でご利用いただいています。 – アルゴリズムマネジメント : scouty 伊藤 勝梧さん AI技術を活用しヘッドハンティングビジネスを展開しているscouty伊藤さんからは、研究とビジネスの違い、技術選定、そして、どこにどのアルゴリズムを用いるかのマネージメントについてお話いただきました。 お話は組織体制にまでおよび、講演後のディスカッションも活発な議論が行われました。 – Lightning Talks AWS FinTech リファレンス・アーキテクチャを作って出した話 ~Compliance as Code~ : AWS Japan 塚田 朗弘 先日、日本版のAWS FinTech リファレンス・アーキテクチャーを公開し、その作成に携わったStartup担当のSenior Solutions Architectの塚田から、改正銀行法成立にともなう今後の動向や、コンプライアンスに関連する要求事項への対応、そしてAWSのソリューションを活用したアーキテクチャ設計および構築についてご紹介しました。 AWS費用の事業部別コスト配分について : エネチェンジ川西智也さん AWSコストの事業部別コスト配分について from Tomoya Kawanishi エネチェンジの川西さんからは、各事業で共通のAWSアカウントを使用しているものの、コストは事業毎に算出したい、といった要件に対してどのように対応しているかご紹介いただきました。 AWS […]

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

これまで、とても長い間、サーバーやその他のクラウドリソースのスケーラビリティについてお話ししてきました！2006年には、「新しいスケーラブルの世界、オンデマンドのWebサービスで必要なものだけにお金を支払って、無駄な出費をしない」という投稿をしました。これを簡単に行えるように、Amazon Elastic Compute Cloud (EC2) のローンチ直後に、Elastic Load Balancing、EC2 Auto Scaling、および Amazon CloudWatch を同時にローンチしました。それ以降、Auto Scaling をECS、Spot Fleets、DynamoDB、Aurora、AppStream 2.0、EMRなどのその他の AWS サービスにも追加してきました。また、アプリケーションに最も適したメトリクスに基づくスケーリングを容易にするために、ターゲットトラッキングなどの機能も追加してきました。 AWS Auto Scaling の紹介 AWS Auto Scaling の導入により、複数の AWS サービスの Auto Scaling 機能を単一のユーザーインターフェイスで簡単に使えるようになっています。既存のサービスに固有のスケーリング機能を、この新しいサービスの構築で統合しています。AWS CloudFormation スタックで説明されているように、アプリケーションの一部である、それぞれの EC2 Auto Scaling グループ、EC2 Spot Fleet、ECS タスク、DynamoDB テーブル、DynamoDB Global Secondary Indexe、および Aurora Replica、あるいは AWS Elastic Beanstalk で動作します (AWS Auto Scalingで使用するアプリケーションとして、一連のリソースにフラグを立てるためのいくつかの他の方法も検討中です）。 リソースとサービスごとにアラームとスケーリングのアクションを設定する必要はなくなりました。お使いのアプリケーションで […]

この記事は、AWS コミュニティヒーローの Cyrus Wong によるゲスト投稿です。 ここ香港にある私たちの学院 (IVE) では、教育、研究、およびヘルスケアにおいて Amazon Lex での実験を開始しました。当学院には、IVE の英語教師、IVE の保育、高齢者およびコミュニティサービス学科のセラピストなど、Amazon Lex コンソールで自然言語での対話ボットを作成する技術的ノウハウを持たない従業員が多数存在します。私たちは、非技術系ユーザーのための Amazon Lex チャットボットを構築する試験的なプロジェクトをいくつか完了しました。非技術系ユーザーは Excel スプレッドシートにそれぞれの質問を記入し、その後開発者が Amazon Lex コンソールにユーザーの質問をコピーしました。しかし、ユーザーがチャットボットで何かを変更したい場合、開発者はいつもこれと同じコピーアンドペーストプロセスを行わなければなりませんでした。 そこで私たちは、「チャットボットの構築に Excel を直接使ってコピーアンドペーストの繰り返し作業をやめたらどうだろう?」と考えました。 当学院の従業員は全員 Microsoft Excel の使用方法を知っているため、私たちは最小限のプログラミングスキルでチャットボットを作成するために Excel を使用できる「ExcelLexBot」というプロジェクトを立ち上げることにしました。 ExcelLexBot は、事前定義されたフォーマットの Excel ファイル (xlsx) を Amazon Lex チャットボットに変換するサーバーレスアプリケーションです。私たちが作り上げた ExcelLexBot は様々な方法で使用することができ、その全てが迅速に、最小限の開発スキルで構築できるように設計されています。私のような教師は、ExcelLexBot を使ってインタラクティブなチャットに似たテストや課題を作成することができます。生徒は、最後の学年末プロジェクトにチャットボットの機能性を追加するためにこれを使用しますが、これも迅速に行うことができます。クラウドおよびデータセンター管理の副学士課程に属する 80 人の生徒たちが 1 時間内で 80 のチャットボットを作成しました。 この記事では、ExcelLexBot の仕組みと、それをデプロイして使用する方法について説明します。 Amazon Lex のコンセプト […]

AWS を拡大するにあたり、まず地域 (リージョンと呼びます) を決定した後、その地域において複数の独立したアベイラビリティーゾーンを開設します。各アベイラビリティーゾーン (AZ) には、数多くのインターネット接続と電源接続があり、さまざまなグリッドにつながっています。 このたび、50 番目の AWS アベイラビリティーゾーンを開設することになりました。新しいゾーンは、欧州 (ロンドン) リージョンにおける 3 番目のゾーンです。これにより、極めてスケーラブルで耐障害性の高い用途をより柔軟に設計し、イギリス国内の複数の AZ で実行できるようになります。 欧州 (ロンドン) リージョンの開設以来、AWS は新しく革新的な用途でますます多くのお客様に利用されています。特に、公共機関や規制の厳しい業界においてこの傾向は顕著です。たとえば、イギリスの AWS 部門の担当者から、次のような事例の報告を受けています。 企業 – BBC、BT、Deloitte、Travis Perkins など、イギリスの大手有名企業が AWS を利用してビジネスを一変させています。イギリスの大手建材業者である Travis Perkins は、データセンターをまるごと AWS に移行するなど、そのシステムとビジネスにおいてこれまでにない規模の変革を実施しています。 スタートアップ – 国際送金サービスの Currencycloud は、支払業務とデモプラットフォームをすべて AWS に移行し、インフラストラクチャのコストを 30% 削減しています。クレジットスコア業界に新風を吹き込む Clearscore は、自社プラットフォームをすべて AWS でホスティングしています。UnderwriteMe は欧州 (ロンドン) リージョンを使用し、引受業務のプラットフォームをマネージドサービスとしてお客様に提供しています。 公共機関 – Met Office は […]

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 […]

以前より AWS をご利用のお客様からは、ガバナンスとコンプライアンスのニーズを満たすため Amazon SageMaker でアクティビティを記録したいというご要望をいただいておりました。このたび、Amazon SageMaker が AWS CloudTrail と統合されたことをご案内いたします。これにより Amazon SageMaker API のアクティビティに関するアカウント情報を記録して継続的にモニターして保持できるようになりました。Amazon SageMaker API コールは、Amazon SageMaker SDK、AWS SDK、Amazon SageMaker 用の Apache Spark SDK、Amazon SageMaker コンソールからキャプチャされ、Amazon S3 バケットに配信されて、AWS アカウントアクティビティのイベント履歴を提供します。記録される情報は、送信元 IP アドレス、リクエストされた日時、リクエストに関連付けられたユーザー ID、リクエストされたパラメーターなどです。 AWS CloudTrail との統合により、Amazon SageMaker には一連の管理機能が追加されます。これは、Amazon が共有セキュリティおよびコンプライアンスにおける責任を果たすための継続的な取り組みの一環です。この機能は Amazon が先月配信した管理機能に基づくものであり、ISO 標準認定に準拠しています。また、Amazon SageMaker におけるガバナンスを重視し、監査に対応した将来的機能の基盤であるとともに、お客様が安全かつ標準準拠の機械学習 (ML) プラットフォームを確立して運用するのに役立ちます。 詳細については、「Amazon SageMaker ドキュメント」を参照してください。 その他の参考資料 Amazon SageMaker でのご利用開始: より正確な時系列予測のための […]

この記事は、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 […]

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