Amazon Web Services ブログ

Category: *Post Types

Amazon Redshift の更新 – ra3.4xlarge インスタンス

クラウドデータウェアハウスサービスとして Amazon Redshift を 7 年以上前にリリースして以来、何万もの顧客がワークロードを構築してきました。私たちは常にお客様のご意見に耳を傾けており、昨年 12 月に、コンピューティングとストレージを別々にスケーリングする機能を備えた第 3 世代の RA3 ノードタイプを発表しました。前世代の DS2 および DC2 ノードではストレージの量が固定されていたため、クラスターにノードを追加してストレージ容量を増やす必要がありました。新しい RA3 ノードを使用すると、ワークロードをサポートするために必要なコンピューティング容量を決定し、ニーズに基づいてストレージの量をスケーリングできます。RA3 ファミリーの最初のメンバーになったのは ra3.16xlarge でした。多くのお客様から、素晴らしいけどワークロードのニーズに必要なレベルを超えているとのご意見がありました。 本日、RA3 ファミリーに小さな新規メンバーである ra3.4xlarge を追加します。 RA3 ノードタイプは AWS Nitro に基づいており、Redshift マネージドストレージのサポートが含まれています。Redshift マネージドストレージは、ストレージのティア全体にわたってデータ配置を自動的に管理し、最もホットなデータを高性能 SSD ストレージにキャッシュし、よりコールドなデータを Amazon Simple Storage Service (S3) に自動的にオフロードします。Redshift マネージドストレージは、ブロック温度、データブロックの経過時間、ワークロードパターンなどの高度な手法を使用してパフォーマンスを最適化します。 マネージドストレージを備えた RA3 ノードは、大容量のストレージ容量を必要とする分析ワークロードに最適であり、最も重要なデータのサブセットが時間とともに常に進化する運用分析などのワークロードにも適しています。以前は、ストレージ制限が固定されていたため、古いデータを他のストレージにオフロードまたはアーカイブする必要がありました。これにより、運用分析データセットとより大きな履歴データセットを維持する必要が生じたときにクエリを実行することが困難でした。 新しい ra3.4xlarge ノードは、12 個の vCPU、96 GiB の RAM を提供し、最大 64 TB […]

Read More

オンラインの方法を使用して、Amazon DocumentDB に移行する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 MongoDB から Amazon DocumentDB に移行するには、オフライン、オンライン、ハイブリッドの 3 つの主なアプローチがあります。詳細については、Amazon DocumentDB への移行を参照してください。 この投稿では、オンラインアプローチを使用して、オンプレミス、あるいは EC2 にホストされた自己管理型の MongoDB クラスターを Amazon DocumentDB に移行する方法について説明します。オンラインのアプローチがダウンタイムを最小限に抑えます。これは、DMS が移行元の MongoDB の oplog から継続的に読み込み、ソース の Amazon DocumentDB クラスターにほぼリアルタイムでそれらの変更を適用するからです。オンラインの方法のデモについては、Video: Live migration to Amazon DocumentDBをご覧ください。 ダウンタイムを最小限に抑え、ソースデータセットが小さい (1 TB 未満) 場合は、オンライン方法が最適です。データセットが 1 TB より大きい場合は、ハイブリッドまたはオフラインのアプローチを使用して、mongorestore […]

Read More

DynamoDB の CloudWatch Contributor Insights が一般公開されました

Amazon DynamoDB では、1 か月あたり数リクエストから 1 秒あたり数百万のリクエストまで、簡単にスケーリングできる完全マネージド型のキーバリューデータベースサービスをお客様に提供しています。DynamoDB は、あらゆる規模で一貫した 1 桁のミリ秒の応答時間を実現することにより、世界最大規模のアプリケーションを複数サポートしています。実質的に無制限のスループットとストレージでアプリケーションを構築できます。DynamoDB グローバルテーブルは、データを複数の AWS リージョンにレプリケートして、グローバルに分散されたアプリケーションのデータにローカルで高速にアクセスできるようにします。マイクロ秒のレイテンシーでさらに高速なアクセスが必要なユースケースでは、DynamoDB Accelerator (DAX) が完全マネージド型のインメモリキャッシュを提供しています。 2019 年 11 月に、Amazon DynamoDB の Amazon CloudWatch Contributer Insights をプレビューとして発表しました。本日、すべての AWS リージョンで一般的にご利用いただけるようになったことをお知らせします。 Amazon DynamoDB の Amazon CloudWatch Contributer Insights 2019 年 11 月に開始された Amazon CloudWatch Contributor Insights は、ログデータを分析し、時系列視覚化データを作成して、システムパフォーマンスに影響を与える上位のコントリビューターを確認できるようにしています。これを行うには、Contributor Insights ルールを作成して、CloudWatch Logs (AWS のサービスからのログを含む) と、自社のサービスまたはオンプレミスサーバーから送信されたカスタムログを評価します。たとえば、不良ホストを見つけたり、最も重いネットワークユーザーを特定したり、エラーを最も多く生成している URL を見つけたりできます。 DynamoDB の上にアプリケーションを構築する開発者にとっては、トラフィックの傾向や頻繁にアクセスするキーなどのデータベースアクセスパターンを理解して、DynamoDB のコストとパフォーマンスを最適化するのに役立ちます。DynamoDB […]

Read More

Amazon DocumentDB 向けのロールベースのアクセス制御 (MongoDB 互換) のご紹介

Amazon DocumentDB (MongoDB 互換) は、MongoDB 3.6 ワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャを気にすることなく、現在ご使用のものと同じ MongoDB 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上で実行や管理をしたり、処理負荷を調整したりするのに使えます。 Amazon DocumentDB にロールベースのアクセス制御 (RBAC) のサポートが追加されました。RBAC では、1 つ以上の事前定義されたロール (たとえば、read、readWrite、または dbOwner) をユーザーに付与できます。これにより、1 つ以上のデータベースで実行を許可されている操作が決まります。RBAC の一般的な使用例は、単一のアプリケーション内で最小権限アクセスを実施することです。もう 1 つの一般的な使用例は、マルチテナントアプリケーションを構築することです。マルチテナントアプリケーションでは、複数の顧客にサービスを提供するソフトウェアとハードウェアをデプロイします。Amazon DocumentDB のコンテキストでは、マルチテナントアプリケーションの例に、各顧客 (またはテナント) がクラスター内のデータベースにアクセスする場合が挙げられます。 この記事では、Amazon DocumentDB の RBAC の概念と機能を紹介し、2 つのユースケースを取り上げ、RBAC を使用してマルチテナントアプリケーションを構築する際の設計上の考慮事項について説明します。新しい RBAC 機能の詳細については、ドキュメントの「ロールベースのアクセス制御 (組み込みロール)」を参照してください。 概念 Amazon DocumentDB は、以下の RBAC の主要な概念を用いています。 ユーザー – 認証して操作を実行できる名前付きエンティティ パスワード – ユーザーを認証する秘密の言葉 ロール – ユーザーが […]

Read More

Amazon EKS ワーカーノードの謎を解くクラスターネットワーク

AWS で Kubernetes を実行するには、AWS のネットワーク設定と Kubernetes のネットワーク要件の両方を理解する必要があります。デフォルトの Amazon Elastic Kubernetes Service (Amazon EKS) の AWS CloudFormation テンプレートを使用して、Amazon Virtual Private Cloud (Amazon VPC) と Amazon EC2 ワーカーノードをデプロイすると、通常の場合、すべて機能します。しかし、設定に小さな問題があると、エラーが発生してイライラさせられることがあります。 このブログでは、Amazon VPC を設定するさまざまな方法を見ながら、Amazon EKS が管理する Kubernetes クラスターの EC2 ワーカーノードを実行します。ノードがクラスターコントロールプレーンに接続できるようにサブネットが適切に設定されていることを確認する方法について、特に注目します。 このブログでは、VPC CNI、サブネットのサイズ設定、ポッドの IP アドレス割り当てなどのポッドネットワーキングの概念については取り上げません。これらのトピックの詳細については、EKS ドキュメントをご覧ください。 注 – VPC とノードの Cloudformation テンプレート、および EK が管理するノードグループがパブリック IP アドレスをノードに割り当てる方法を変更しています。詳しくは ブログをご覧ください。 EKS クラスターのアーキテクチャ EKS クラスターは […]

Read More

AWSも提言を行った、農水省DX室の「デジタル地図」構想がプレスリリースに至りました

農林水産省(以下「農水省」)様より、”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめ” が公開されました(2020年3月下旬公開、以下「取りまとめ」)。2019年秋以降、本検討会へはAWSメンバーも参加して各種の提言を行って参りました。以下、AWSパブリックセクターより、本「取りまとめ」の意義や要点を解説しながら、農林水産政策分野やデジタル地図に関連するAWSのサービスや事例をご紹介させていただきます。   ❖「デジタル地図」検討会設置の目的 農水省では、現状の”農地情報は各施策の実施機関ごとに個別に収集・管理されている”こと、つまりは情報が散在していることに起因し、 1)農業者は、同様の情報でも実施機関ごとに個別に申告、 2)実施機関ごとに、農地情報を独立したデータベースで管理、 3)現地確認も実施機関ごとに実施しているため、情報の整合性を保つための突合作業等は大きな負担となっており、また、整合性が取れていないケースもあるといった状態 ────といった問題があることを特定しました。 これらの問題意識から出発し、農水省DX室は今回の「デジタル地図」を活用した農地情報の管理に関する検討会の設置を決め、約半年間に渡り活動を重ねてきました。この、先進技術と政策の融合を目指した取り組みに関しては、「農地情報をデジタル地図に 農水省が一元化」と題して日経新聞など各種メディアでも報じられていたところです。 検討会での主な論点となったのは、「農地情報の一元的な管理を可能とする技術的環境が整備されつつある」なか、いかにして「農地情報の正確性と整合性を確保しつつ、農業者や実施機関等の関係者の負担軽減を図ることができる」か──という点です。特に、「幅51cmもの、農地転用に関する分厚い書類」「2,136時間&57,300枚が、経営所得安定対策の申請受付等に費やされる」「7,200経営体が22,000筆のデータを個別にPDF化し打ち込み」といった全国の農業関係者が直面する困難がデータポイントで列記される「第2章 現状と課題」は圧巻です。 これらの負担を先端技術により解決することを目指した本検討会においては、クラウドを活用することで高水準で実現することができる”拡張性”・”信頼性”・”柔軟性”・”堅牢性”・”可用性” 等の観点から整理をいただき、”システムの構築・運用に当たっての原則”として記載をいただいております。詳しくは、「取りまとめ」の“第5章 デジタル地図のシステム要件”をご参照ください。 (参考) ↓:「取りまとめ」文書中の、システムの構築・運用の原則 こうした方向性のもと取りまとめられた今回の農水省DX室のイニシアティブが、以下サイトにてプレスリリースされました: ”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめについて”   ❖ AWSからの提言:クラウドが「デジタル地図」の有効活用を加速する 農水省の「取りまとめ」には、幾つもの政策的・技術的に踏み込んだ内容が記載されており、以下のとおりAWSからの提言と合致する論点も盛り込まれています: オンプレからクラウドへの転換:「従来のオンプレミス[・・中略・・]では、限られたネットワーク内でしかGIS[注:地理情報システム]上の地図情報の閲覧、編集ができなかったが、クラウドベースのGISを活用することにより、インターネット接続による地図情報の閲覧、編集が格段と容易になる」との記載にて、クラウドベースでの技術のメリットを明記いただいています。 ”地図”に関連し、DX室にも紹介させていただいた、高精度地図データ配信にAWSの機械学習モデルを活用した株式会社ゼンリンデータコム様の事例に関しては、こちらをご覧ください。 拡張性の高いデータベース:「データベース管理については、将来的なデータ項目の追加や、レコード数やアクセス数の増大等によるアクセス速度の低下防止に対応できるようにすることが重要であるが、データ項目の柔軟な加除やシステムの高速化を可能とするNoSQL等の新しいデータベース管理手法も活用可能となってきている」との記載にて、新型のDBMS採用を模索する方向性を明記いただいています。NoSQLデータベースを含む、AWSのデータベースサービスの全容に関してはこちらをご参照ください。 超大規模データのオープン化:「国や地方自治体において、様々なデータをリアルタイムで集約し、データに基づいた多元的な分析を行うことで、農業施策に反映させることで、課題の的確な把握・対応を可能とする。また、集約されたデータをオープン化することで、研究機関等による多様なデータ分析に基づいた政策提言を容易にする」との記載にて、オープンデータ化の方向性を明記いただいています。オープンデータを加速するAWSの取り組みに関してはこちらをご覧ください。特に、公的機関向けにストレージ費用をAWSが負担する「AWS Public Dataset Program」は現在、「衛星画像」「地理情報」「気候」等のカテゴリーを設け、NOAA(アメリカ海洋大気庁)等が収集した、合計で120を超えるDatasetを公開しております(2020年3月現在)。 パブリッククラウドとLGWANとの接続:「地方自治体においては関係業務がLGWAN環境で行われる一方、現場におけるインターネット環境でのタブレット等による農地情報の閲覧、編集のニーズがあることを踏まえ、LGWANとインターネットのハイブリッド方式を採用」「LGWANとパブリッククラウドの接続のあり方に関しては現在総務省において検討が進んでおり、その結果を踏まえ、必要な検討を行う」との記載にて、農業関係者皆様にとっての高い利便性確保のための整理が待たれる旨、明記いただいています。 AWSは、クラウドが次世代の農業をサステナブルかつ、魅力的な産業へと進化させていくことに強くコミットしています。自身も農業の盛んな米国ケンタッキー州の出身であると回顧することから始まるテレサ・カールソン(AWS Worldwide パブリックセクターのバイスプレジデント)のブログも併せてご参照ください:”Mission: Technology-enabled, sustainable agriculture”。   ❖ 提言させていただいたAWSのサービス 今回の農水省の検討会では、以下のAWSサービスが特に「デジタル地図」の構想と親和性が高いものと判断し、提言に盛り込ませていただきました。 データレイク構築の要となる“Amazon S3(Simple Storage Service)”:様々なデータを分析し正しい意思決定を行うためには、規模にかかわらず、全ての構造化データと非構造化データを長期間、安全に保存することが可能な「データレイク」を構築する必要があります。Amazon S3を活用いただくことが、圧倒的低コストでのデータレイク構築のための近道です。 軌道衛星からのデータを受信する “AWS Ground Station”:天気予報、地表画像撮影、通信、放送など軌道衛星からのデータを、独自の地上基地局を管理することなくご活用いただけます。AWS Grand Stationで受信されたデータは、AWSグローバルインフラストラクチャ(世界規模の低遅延ファイバーネットワーク)を経由し、Amazon S3等へ蓄積し利活用が可能です。 Amazon DynamoDBなど多種多様なデータベース:データ処理を高速、低コストで実現するためには、アプリケーションや利用ユースケースに最適なデータベースを無理なく選択する必要があります。AWSが提供しているデータベースは、一般的な利用ユースケースをほぼ網羅するデータベースが7分類あり、AWS上で簡単に相互連携することで、高速、低コストなデータ処理を実現可能です。 ”Amazon […]

Read More

『クラウド調達に関する10の考慮事項』のホワイトペーパー和訳版を公開しました

AWSパブリックセクターより、これまで英語版でのみ閲覧頂いていましたホワイトペーパー『Ten Considerations for a Cloud Procurement』の和訳版が公開されましたのでお知らせします(下記ウェブページからダウンロードいただけます  https://d1.awsstatic.com/whitepapers/ja_JP/10-considerations-for-a-cloud-procurement.pdf?did=wp_card&trk=wp_card)。 多くの場合、官公庁や教育機関などパブリックセクターの各機関のお客様においては、過去のソフトウェア調達、物品調達の調達仕様書・要件定義書を参考にしながら、クラウドサービス調達の検討を進めることになると考えられます。今回のホワイトペーパーでは、AWSのこれまでの多くのお客様との意見交換やベストプラクティスを踏まえ、そうした検討を進めるにあたってまず考慮いただくべきハイレベルな考え方を、以下の10の切り口から整理しています。 クラウドコンピューティングの違い; カスタマイズ性が高い製品を購入し物理的資産として所有・管理するものでなく、標準化された市販のサービスをオンデマンドで利用するもの。 早期にクラウドのメリットを引き出せるように計画する; すべての主要な関係者が早期より関与すべき 過度に規範的に要求しない; データセンター等に関しカスタマイズされた調達仕様(例 ラック、サーバーのタイプ、データセンター間の距離など)を指示する必要はなく、商用クラウド業界の標準やベストプラクティスを活用。不用意な制約を避け、革新的でコスト効率の高いソリューションを活用していく クラウドインフラストラクチャ(IaaS)と、その活用のためのサービスを分けて考える; システムの設計・開発・運用として包括的に調達するにせよ分離して調達するにせよ、クラウドインフラストラクチャはそれ自体に責任分界・SLA・利用規約が設定されている別個のサービスとみておく “従量課金”; “毎月末に使用した分の料金を支払う” “市場価格に基づいて変動する柔軟な料金体系” セキュリティ、プライバシー、監査について第三者認証等を活用; FedRAMP, SOC, ISOなど セキュリティは“責任共有モデル”; IaaSモデルでは、クラウド事業者は強固なインフラを構築し、様々なセキュリティ機能を提供。これらを活用してシステムを構成し、アプリケーションやデータをコントロールするのは利用者 データガバナンスの設計・実装; クラウド利用者はデータの統制と所有を完全に保持(クラウド事業者はデータ管理しない)。この原則を前提に検討を進めることが必要。 “市販品”の利用規約; クラウドコンピューティングは民間利用者も政府利用者も同じ利用規約の下で利用するもの。どの事業者の利用規約が適切か考慮した上で、これを組み込んでいくという考え方。 “クラウド評価基準”を定義する; 性能要件に照準をおき、適切なクラウド事業者を選定していくとの考え方   調達担当者にとってクラウドサービスに適合的な調達仕様書を作り込むことは、チャレンジと言えますが、今回の和訳版は、日本政府が推進する「クラウド・バイ・デフォルト原則」の下で具体的な調達プロジェクトに取り組む日本の調達担当者の皆様に、グローバルな議論の積み上げを知っていただく指針の一つとして活用いただけるものと考えています。今後、AWSとしては、このホワイトペーパーやその他資料のご説明の機会を日本のパブリックセクター領域の皆様に提供し、更に活用し易くすると同時に、具体的な調達プロジェクトへの当てはめを含め、各機関からの相談にも対応していきたいと考えています。 今回の資料をご覧いただき、「なんとなくわかる気もするけど、具体的にはどういうこと?」「日本ではどう理解したらいいの?」等々様々な疑問やご質問がありましたら、ぜひ、AWSパブリック・セクター公共調達渉外担当までお問い合わせください。 なお、英語版原文は下記より参照可能です。https://aws.amazon.com/jp/blogs/publicsector/ten-considerations-for-a-cloud-procurement/ 本ブログは、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐の小木郁夫・市ノ渡佳明が執筆いたしました。

Read More