Amazon Web Services ブログ

Amazon RDS for SQL Serverがローカルタイムゾーンをサポートしました

Amazon RDS SQL Serverでローカルタイムゾーンをサポートしました。アプリケーションでお使いのタイムゾーンをAmazon RDS for SQL Serverインスタンスに設定頂けます。 こちらの機能はDBインスタンスのタイムゾーンをご指定の物に設定します。RDS for SQL Serverを作成する際にタイムゾーンを変更する場合は、AWS Management ConsoleのSelect your Time Zoneドロップダウンメニューを利用します。インスタンス作成後はタイムゾーンを変更することが出来ません。このオプションを変更すると、OSレベルでのタイムゾーンの変更が行われ、全てのdateカラムと値に影響がある点ご注意ください。その為、タイムゾーンの変更による影響を事前に調査することを推薦します。ローカルタイムゾーンを設定したデータベースインスタンスを作成する前に、テストデータベースインスタンスで変更を検証することをお勧めします。 Amazon RDS for SQL Serverのローカルタイムゾーンサポートに関する更に詳細な情報は、ドキュメントをご覧ください。 星野 (原文はこちら)

Read More

週刊 AWS – 2016 年 9 月 12 日

ご協力ありがとうございました!合計 25 人の内外部の寄稿者が、今回の週刊 AWS の作成に協力してくださいました。自分もぜひ参加していみたいという方は (re:Invent でランチ無料の可能性あり)、GitHub の週刊 AWS をご覧ください。 月曜日 9 月 12 日 がブログ「Amazon ECS と Amazon CloudWatch ログでコンテナログを一元管理」を公開しました。 [backspaceblog] がアプリケーションのフロントエンドセキュリティ「責任分担 3 – ボットの特定と破棄」について説明しました。 John McKim が AWS の「サーバーレスフレームワークと Slack Webhooks」についてブログを公開しました。 Darin Briskman が「Redis でシンプルな自動入力機能サービスを作成: パート 1」についてブログを公開しました。 が「Amazon ECS と Amazon CloudWatch ログでコンテナログを一元管理」を公開しました。 が AWS サービスアップデートについて大量の情報を含むエピソードを公開しました。 FittedCloud が LVM を使用した AWS EBS の最適化とコスト節約の方法に関するブログを公開しました。 […]

Read More

新機能 – AWS コストエクスプローラーの追加のフィルタリングオプション

AWS コストエクスプローラーは、AWS 使用量の視覚化、理解、管理に役立つ強力なツールです (詳細については、「The New Cost Explorer for AWS」を参照してください)。サービスまたはリンクされたアカウント別に使用量を表示でき、日または月単位を選択できます。アカウント、期間、サービス、またはお客様が特に関心を持っているタグに基づいて、カスタムフィルターを作成することもできます。使用量の可視性をさらに高めるため、いくつかの追加のフィルタリングオプションを導入しました。現在では、さらにきめ細かなレベルでフィルタリングし、最も基本的な課金単位までズームインして費用を表示できるようになりました。また、ズームアウトし、AWS 使用量および請求の主要コンポーネントに合った高位のレベルで使用量を分類することもできます。 ズームイン お気付きかと思いますが、AWS は使用量を非常に詳細なレベルで追跡できます。S3 ストレージの毎時のギガバイト、EBS 使用量の毎月のギガバイト、毎時の EC2 使用量、内部または外部へのデータ転送ごとのギガバイトなどです。これらの費用を、[Usage Type] フィルタリングオプションを使用して詳細に確認できるようになりました。コストエクスプローラーに移動して [Filtering] メニューから [Usage Type] を選択すると、基本的な請求単位に基づいてフィルタリングできるようになりました。たとえば、m4.xlarge インスタンスの毎日の使用量を表示できます。 ズームアウト 詳細情報が必要なときもあれば、概要が必要なときもあります。RDS の使用量、S3 API リクエストの使用量、EBS 磁気ストレージの使用量を知りたいときもあります。この操作は、[Usage Type Group] を基にしてフィルタリングすることで実行できます。私の毎日の EC2 使用量は次のとおりです フィルタリングに使用できる他の使用量タイプグループをいくつか次に示します (メニューの高さについては、ブラウザで特別な操作を行っています)。 今すぐ利用可能 これらの新機能は今すぐすべての AWS リージョンで利用できます。

Read More

AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換

では、テンプレートを作成して、スタック全体 (関連する AWS リソースのコレクション) を宣言により表すことができます。スタックを定義し、希望のリソースとそれらの相互関係を指定および設定して、スタックの必要な数のコピーを起動できます。CloudFormation では、リソースを自動的に作成およびセットアップし、リソース間の順序付けの依存関係の対応に配慮することもできます。現在、CloudFormation には 3 つの重要な機能を追加中です。 YAML Support – CloudFormation テンプレートを YAML で記述できるようになりました。 クロススタック参照 – あるスタックから値をエクスポートし、別のスタックで使用できるようになりました。 簡略化された置換 – テンプレート内で文字列の置換をより簡単に行うことができます。 それらについて説明します。 YAML のサポート CloudFormation テンプレートを YAML (「YAML はマークアップ言語ではない」の頭文字) で記述できるようになりました。これまでは、テンプレートは JSON で記述されていました。YAML と JSON の表現力は同等ですが、YAML は人間が読み取れる形式であるよう設計されているのに対して、JSON は (正直なところ) そうではありません。YAML ベースのテンプレートでは句読点の使用が少なく、記述と読み取りがかなり簡単です。また、コメントの使用が許可されます。CloudFormation は、ハッシュ結合、エイリアス、および一部のタグ (バイナリ、imap、ペア、TIMESTAMP、セット) の例外を除き、実質的にすべての YAML をサポートします。 YAML で CloudFormation テンプレートを記述する場合、同じ最上位の構造 (Description、Metadata、Mappings、Outputs、Parameters、Conditions、および Resources) を使用します。これは、パラメーター定義を図示したものです。 Parameters: DBName: […]

Read More

Earth on AWS: AWS の地理空間データ

AWS のオープンデータチームのメンバーで私の同僚、Joe Flasher が新たな Earth on AWS プロジェクトについて説明するため、ゲスト投稿者としてブログを公開しました。   AWS は地球観測衛星のランドサット 8 号が撮影した画像を集めた公開データセット、Landsat on AWS を 2015 年 3 月にリリースしました。Landsat on AWS をリリースしてから 1 年以内に記録された Landsat データのリクエスト数は 10 億件を超え、AWS はユーザーによる革新的なデータの使用方法から様々なインスピレーションを得ています。Landsat on AWS はクラウド内でのデータ共有により、従来の IT インフラストラクチャによる帯域幅やストレージ、メモリや処理能力の制限なしに地球的規模のアプリケーションを構築することが可能になりました。 そして本日、AWS がリリースした Earth on AWS により、今後はクラウド内で大容量の地理空間データセットの利用が可能になったため、アルゴリズムをローカルマシンにダウンロードせずにアルゴリズムをデータに持ち込めるようになりました。Earth on AWS では誰でも自由にデータを使えるだけでなく、リソースを提供することでデータをどのように使用できるか説明する情報も提供しています。また、Earth on AWS データセットを利用した調査方法の 公開プロポーザル も受け付けています。 使用可能なデータを追加 現在、Earth on AWS には次のデータセットがあります。 NAIP […]

Read More

Amazon RDS for PostgreSQL – 新マイナーバージョン、ロジカルレプリケーション、 DMSサポートなどを追加 –

Amazon Relational Database Service (RDS)は構築や運用管理、スケーリングなどを行うプロセスを簡単に行えるクラウド上のリレーショナルデータベースです。現在6つのデータベースエンジン(Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL,  MariaDB) をサポートしており、RDSはクラウド上で動作するアプリケーションの基本となるサービスとなりました。 2013年後半にPostgreSQLサポートを発表し、PostgreSQLの新バージョンや新機能を追加し続けてきました。 2014年11月 – Read Replicas, version 9.3.5, Trigger-based Replication, and Three New Extensions. 2015年3月  – Version 9.4.1, Enhanced Monitoring, Enforced SSL Connections. 2015年11月 – Point and Click Upgrade from Version 9.3 to 9.4. 2016年4月  – Versions 9.3.12, 9.4.7, and 9.5.2. 2016年6月 […]

Read More

AWS オンラインセミナー – 2016 年 9 月(英語によるセミナー)

今月始めに継続学習のメリットについて説明したブログを公開し、継続学習と昇給、効率性の向上や転職の傾向が減少する関連性について表したインフォグラフィックをご紹介しました。AWS のイノベーションのペースは、いつも何か新しいことを学べるチャンスがあることを意味しています。これを実践するには AWS のオンラインセミナーに参加するのも 1 つの方法です。AWS ではこうしたオンラインセミナーをデザインする上でトレーニングと教育の面を考慮しています。そうすることで、参加者は新しい AWS サービスを使い始める準備を整えることができるほか、既存のサービスを別の方法で活用するための知識を得ることができると考えています。9 月に開催するオンラインセミナーにも素晴らしい内容が揃っています。いつもながら受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所要時間は 1 時間です。 9 月 20 日 午前 9:00 – 詳細: ビッグデータ分析に Amazon Redshift を使用 午前 11:30 – コンテナを大規模にモニタリング 9 月 21 日 午前 9:00 – Cognito ユーザープールの使用開始について: アプリで簡単にユーザーのサインアップとサインインを追加 午前 11:30 – データウェアハウスを Amazon Redshift に移行する場合のベストプラクティス 午後 1:00 – Amazon Elasticsearch Service のログ分析 9 月 22 […]

Read More

週刊 AWS – 2016 年 9 月 5 日

これは、週刊 AWS 第 3 回目のコミュニティ型エディションです。これを実現するために貢献してくださった 15 名の内外部寄稿者に感謝申し上げます。寄稿を希望される場合は、GitHub の週刊 AWS をご覧ください。 月曜日 9 月 5 日 John McKim が AWS のサーバーレスフレームワークと GraphQL についてブログを公開しました。 火曜日 9 月 6 日 AWS Config を使用して設定変更に関係する API イベントの表示が可能になったことを AWS が公表しました。 本稼働環境で AWS SDK for C++ の使用が可能になったことを AWS が公表しました。 IAM Service Last Accessed Data がアジアパシフィック (ムンバイ) リージョンで利用可能になったことを AWS が公表しました。 が自動推測や Amazon s2n […]

Read More

Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーション、アカウント間でのスナップショットの共有、フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。 本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。 Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。 Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。   Find the Endpoint リーダーエンドポイントはAurora Consoleで確認可能です: この便利な機能は本日からご利用可能です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

MeetMe での S3 データレイクへのリアルタイムデータのストリーミング

本日のゲスト投稿では、MeetMe の Anton Slutsky 氏が、自社のデータレイク用の実装プロセスについて説明します。 Anton Slutsky 氏は、この分野で 20 年近い経験を持つ経験豊富な情報技術者です。ビラノバ大学でコンピューター科学の修士号を取得し、ドレクセル大学で情報科学の博士号を取得しています。 現在のビッグデータシステムには、しばしばデータレイクと呼ばれる構造が含まれています。データレイクという業界用語は、大量の構造化データと非構造化データを吸収し、多数の同時分析ジョブを実行する機能を備えた大規模なストレージおよび処理サブシステムのことです。 はスケーラブルで信頼性が高く、レイテンシーが短いストレージソリューションを低いオペレーションのオーバーヘッドで提供するため、データレイクインフラストラクチャとして現在人気の高い選択肢となっています。ただし、S3 によってペタバイト規模のストレージのセットアップ、設定、管理に関連する多くの問題が解決される一方で、S3 へのデータの取り込みがしばしば課題となっています。これは、ソースデータのタイプ、ボリューム、速度が組織によって大きく異なっているためです。このブログでは、 を使用して MeetMe で大規模なデータ取り込みを最適化、合理化する当社のソリューションについて説明します。これは毎日数百万人のアクティブなユーザーに対応している人気の高いソーシャル検出プラットフォームです。MeetMe のデータサイエンスチームは、1 日あたり約 0.5 TB のさまざまなタイプのデータを、データマイニングタスク、ビジネス向けレポート、高度な分析に公開するような方法で収集、保存する必要がありました。チームはターゲットのストレージ機能として Amazon S3 を選択し、大量のライブデータを堅牢で信頼性が高く、スケーラブルで運用費用が低い方法で収集するという課題に直面していました。ここでの全体的な目的は、可能な限り低いオペレーションのオーバーヘッドで、AWS データインフラストラクチャに大量のストリーミングデータをプッシュするプロセスをセットアップすることでした。Flume、Sqoop など多くのデータ取り込みツールが現在入手可能ですが、当社は、その自動的なスケーラビリティと伸縮性、設定と管理の容易さ、それに S3、、 など他の Amazon サービスとの即座の統合機能により、Amazon Kinesis Firehose を選択しました。 ビジネス価値 / 正当化 多くのスタートアップ企業と同じように、MeetMe は最大のビジネス価値をできるだけ低いコストで提供することに焦点を置いています。したがって、データレイクについては次のような目標がありました。 効果的な意思決定のための高レベルなビジネスインテリジェンスでビジネスユーザーに力を与える。 収益を生み出す洞察の発見に必要なデータをデータサイエンスチームに提供する。 Scoop や Flume といったよく使われているデータ取り込みツールを検討した結果、データサイエンスチームはデータ取り込みプロセスをセットアップ、設定、調整、維持するためにフルタイムの BigData エンジニアを追加する必要があり、冗長性のサポートを可能にするために、エンジニアリングの時間がさらに必要であると予測されました。このようなオペレーションのオーバーヘッドは MeetMe でのデータサイエンスの費用を増やし、全体的な速度に影響する不要な範囲をチームにもたらします。 サービスにより多くの運用面の懸念が軽減され、それによりコストも削減されました。それでもある程度の社内の統合開発は必要でしたが、データコンシューマーのスケーリング、管理、アップグレード、トラブルシューティングは Amazon によって行われるため、データサイエンスチームの規模と範囲は大幅に減りました。 Amazon Kinesis Firehose […]

Read More