Category: Storage

Alkami や Acadian Asset Management などのお客様は、AWS Storage Gateway を使用して Microsoft SQL Server データベースを直接 Amazon S3 にバックアップし、オンプレミスのストレージ占有領域を削減し、耐久性、拡張性、および費用対効果の高いストレージとして S3 を活用しています。 Storage Gateway は、オンプレミスアプリケーションに対して、実質的に無制限のクラウドストレージへのアクセスを提供する、ハイブリッドなクラウドストレージサービスです。このサービスは、ストレージ管理を簡素化し、3 つの主な使用例でコストを削減します。 クラウドへのバックアップ移動 クラウドベースのファイル共有によるオンプレミスストレージの削減 オンプレミスアプリケーション用に AWS 内のデータへのアクセスを低レイテンシーで提供 この記事では、Storage Gateway のファイルゲートウェイ設定を使用してバックアップをクラウドに移動する 1 つの方法を説明します。 概要 次の手順を使用してファイルゲートウェイをデプロイし、SQL Server のバックアップターゲットとしてファイル共有を作成して、S3 にバックアップを保存します。 オンプレミス環境にファイルゲートウェイをデプロイします。 ファイル共有認証でドメインユーザーとグループを使用できるように、ファイルゲートウェイを Microsoft Active Directory ドメインに接続します。 ファイルゲートウェイに SMB ファイル共有を作成し、その共有を S3 バケットに関連付けます。Active Directory ドメインを使用して共有へのオンプレミスアクセスを設定します。 共有をマウントしてクイックバックアップを作成し、SQL Server がその共有にアクセスできることを確認します。 ファイルゲートウェイをデプロイする 始めるには、オンプレミス環境でファイルゲートウェイを作成します。ファイルゲートウェイは、オンプレミスの […]

AWS は、OLTP ワークロードを処理するデータベースをホストするために複数のオプションを提供しており、Amazon EC2 インスタンスで独自のマネージドデータベースをホストする、または AWS が管理する Amazon RDS を使用することができます。RDS は、高可用性、自動バックアップ、データベースのアップグレード、OS パッチ、セキュリティ、およびリードレプリカを管理します。RDS は、クラウドネイティブのオプションである Amazon Aurora データベースエンジンも提供し、このエンジンは MySQL および PostgreSQL に対応しています。Aurora は、標準の MySQL と PostgreSQL データベースよりも優れたスループットを実現します。 Amazon RDS または Amazon EC2 を使ってホストされているデータベースで実稼働ワークロードを実行している時は、次のような疑問を思い浮かべたことがあるかもしれません。 最良のデータベースストレージタイプのオプションは何か? ストレージのパフォーマンス問題はどのように解決すればよいのか? EC2 インスタンスでホストされているデータベースに対する RAID 設定オプションには何があるのか? 最適なパフォーマンスのためのアプリケーション変更は何か? Amazon CloudWatch を使用してストレージパフォーマンスのトラブルシューティングを行うにはどうすればよいのか? Amazon RDS とAurora の運用パフォーマンスの違いは? この記事では Amazon RDS または EC2 インスタンスでホストされているデータベースで実稼働ワークロードを実行するためのストレージのベストプラクティスについて説明します。 テスト、QA、またはステージングの環境と比べて、実稼働ワークロードには高速で一貫した I/O パフォーマンスが必要です。リレーショナルデータベースは多目的に使用できますが、それらの最も一般的なユースケースはオンライントランザクション処理 (OLTP) […]

Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。 2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました（多くのケースで単純にSDKのアップデートを行うだけです）が、SigV4を使用するために、サポートを延期してもらえないかという多くのご要望をいただきました。 新しい日付、新しいプラン オリジナルのプランに関するフィードバックに応じて、重要な変更を行っていきます。概要は次のとおりです。 オリジナルのプラン — SigV2のサポートは2019年6月24日に終了します。 改訂されたプラン — 2020年6月24日以降に作成された新しいバケットは SigV2 署名付きリクエストはサポートされません。ただし、既存のバケットについて引き続き SigV2 がサポートされますが、我々はお客様が古いリクエスト署名方法から移行するよう働きかけます。 既存のバケット、それは SigV2 をサポートする一部のAWSリージョンにおいて、SigV2 を引き続き使用することはできますが、SigV4 に移行することを強くお勧めします。そのことで重要なセキュリティ上のメリットと効率性のメリットが得られます。この新しい署名方法では、長期のAWSアクセスキーから派生した、別途これに特化した署名キーを使用します。このキーは、サービス、地域、および日付に固有です。これにより、サービスとリージョン間の分離が強化され、キーの再利用に対する保護が強化されます。内部的に、SigV4 実装では認証チェックの結果を安全にキャッシュすることができます。これにより、レイテンシーが改善され、アプリケーションの全体的な堅牢性向上が期待できます。詳細については、「署名バージョン4の変更点」を参照してください。 SigV2 を使っているかどうかの判断方法 S3 は 2006年以来からのAWSサービスです。あなたやあなたの前任者が書いたコードの一部はまだまだ現役で利用されている可能性があり、SigV2で署名された要求を忠実に行っているかもしれません。CloudTrailのデータイベントまたは S3 サーバーアクセスログを使用して、この古風なリクエストを見つけることができますので、そのアプリケーションを更新対象にしてください。 CloudTrailのデータイベント — 各 CloudTrail イベントエントリの additionalDataElement 内で SignatureVersion 要素を探します（詳細については、「AWS CloudTrail を使用して Amazon S3 署名バージョン2リクエストを識別する」を参照してください）。 S3 サーバーアクセスログ […]

先週(4/30)、私たちは非常に静かな（実際には静かすぎる）発表を行いました。S3 バケット内のオブジェクトのアドレスを指定するために使用される、パスベースのアクセスモデルについて、ゆっくりとそして慎重に廃止するという計画です。私はこのブログ記事を書くために、状況をよりよく理解すべく、S3チームと話し合うことに時間を費やしました。私が学んだことは以下です… S3 は、2006年の始めにサービスが開始されました。S3 における Jeff Bezosの考える元々の仕様は、非常に簡素なものでした。彼はインターネットにおける malloc （C言語プログラムにおけるキーメモリ割り当て関数）に相当するようなものを望んでいました。その出発点から、S3 は何兆ものオブジェクトを格納し、毎秒数百万のリクエストを処理するところまでに成長しました。 13年間にわたり、S3 には多くの新しいストレージオプション、機能、およびセキュリティ制御が追加されました。 Old vs. New S3は現在、2種類のアドレスモデルを提供しています。path-style と virtual-hosted styleです。一つずつ見てみましょう。まず、path-style モデルでは、次のように見えます（グローバルなS3エンドポイントです）: https://s3.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg https://s3.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png もしくは、次のような形です（リージョナルなS3エンドポイントです）: https://s3-us-east-2.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg https://s3-us-east-2.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png この例では、jbarr-public と jeffbarr-public がバケット名であり、/images/ritchie_and_thompson_pdp11.jpeg と /jeffbarr-public/classic_amazon_door_desk.png がオブジェクトキーとなります。 仮に、オブジェクトが別々の AWS アカウントによって所有されたり、異なる S3 バケット（また場合によっては異なる AWS リージョン）にあったとしても、どちらも同じ DNS サブドメイン s3.amazonaws.com にあります。次に、対応する virtual-hosted style の参照方法を見てみましょう（これらは「新しい」と思われるかもしれませんが、少なくとも2010 年以降に存在しています）: https://jbarr-public.s3.amazonaws.com/images/ritchie_and_thompson_pdp11.jpeg https://jeffbarr-public.s3.amazonaws.com/classic_amazon_door_desk.png これらの URL は同じオブジェクトを参照しますが、オブジェクトは別々の DNS サブドメインにあります (それぞれ […]

先日 (2019/3/19) 開催しました AWS Black Belt Online Seminar「Amazon FSx for Windows File Server/Lustre」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 Amazon FSx for Lustre 20190319 AWS Black Belt Online Seminar Amazon FSx for Lustre from Amazon Web Services Japan Amazon FSx for Windows File Server 20190319 AWS Black Belt Online Seminar Amazon FSx for Windows Server from Amazon Web Services […]

先日 (2019/3/20) 開催しました AWS Black Belt Online Seminar「Amazon EBS」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190320 AWS Black Belt Online Seminar Amazon EBS from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. EBSスナップショットを取得した際のスナップショットのサイズを確認する手段を教えてください。 A. 現在のところ確認する手段はありません。 Q. DLMがEC2一時停止できる環境でおすすめな理由を教えてください。DLMはEC2停止が必須なのでしょうか。 A. DLMで取得されるEBSスナップショットの整合性レベルはクラッシュコンシステンシ−のレベルとなり、アプリケーションレベルでの整合性は保証されません。（メモリ上にまだ未コミットのデータがある場合は、その情報は保管されません）そのため、厳密なデータ整合性が必要な場合は、IOが発生しない状態での取得をお勧め致します。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 AWS Innovate オンラインカンファレンス ≫ 申込先 2019 年 4 月 8 日〜5 月 7 日期間中いつでもオンラインで視聴可能 AWS基礎、業種別事例、人材育成、認定対策講座などAWSが厳選した33セッションを一挙に公開 — AWS Black Belt […]

先日 (2019/2/20) 開催しました AWS Black Belt Online Seminar「Amazon S3/Glacier」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

このブログでは、Amazon S3へのカスタマーアクセスポリシーを作成する方法について説明します。 これらのバケットはデフォルトでは公開されていません。このブログではさらに踏み込んで、Amazon Connectのレポートと通話録音が保存されているバケットをAmazon Connectにロックします。 Amazon Connectアカウントに割り当てられた適切な権限を使用することで、スケジュールされたレポートと保存されたレポートを表示したり、Amazon Connectインターフェイスから通話録音を再生したりできます。 セキュリティとデータのプライバシーは多くの顧客にとって最優先事項であるため、組織やプライバシーの要件を遵守することが重要です。 そのためには、IAMポリシーを使用して、Amazon S3に格納されているAmazon Connectアーティファクトのセキュリティをさらに強化することができます。 これは、顧客情報を危険にさらす可能性があるデータ漏洩または侵害を回避するのに役立ちます。 これにより、顧客のプライバシーを維持するためのセキュリティが強化され、ローカルの規制を遵守するのに役立ちます。 警告 セキュリティ設定を変更するときは注意してください。 これらの変更は恒久的なものであり、あなた自身のアクセスを制限してしまうかもしれません。まずはテストバケットで試すことをお勧めします。 もし間違えると、管理しようとしているリソースへのすべてのアクセスが失われるかもしれません。 これは、Amazon Connectインスタンスの動作に悪影響を及ぼす可能性があります。本番環境で行う前に、テストS3バケットでアクセス制限を試してみることを検討してください。 この記事で説明する次の手順は、S3バケットへのアクセスを制限するために必要です。 インスタンスに使用されているS3バケットを特定する Connectに使用されているIAMロールを特定する コマンドラインを使ってロールIDを特定する S3バケットポリシーを作成する S3バケットへのアクセスを確認する それでは始めましょう。 S3バケットを特定する Amazon Connectインスタンスに関連付けられているバケットを特定します。 インスタンスの作成時に既存のS3バケットを使用しなかった場合は、新しいバケットが作成されています。 次の例に示すように、Amazon Connectダッシュボードで、Amazon Connectに使用されているバケットを見つけることができます。 私のインスタンスの例で使用されているバケット名は、connect-25fd0a3be3ef です。 IAMロールを特定する Amazon Connectサービスに使用されているIAMロールを特定します。Amazon Connectインスタンスでの権限は、IAMロールにより許可されています。 注：Amazon ConnectはService-linkedロールを導入しました 。 この記事の手順は、2018年10月17日にService-linkedロールが導入される前に作成されたAmazon Connectインスタンスに適用されます。 近日中に、この記事をService-linkedロールに関する情報で更新する予定です。 Amazon ConnectサービスのIAMロールを見つけるには IAMコンソールを開きます。 Amazon Connectインスタンスを作成したときに作成されたロールを見つけます。 複数のインスタンスを作成した場合は、作成時間を確認することで、どのロールが各インスタンスに関連付けられているかを判断できます。 作成時間の列が表示されていない場合は、ページの右上隅にある歯車のアイコンから追加できます。 どのロールがどのインスタンスに対応しているか判断できない場合は、ロールがアクセス権を持つS3バケットが、そのインスタンスで使用されるバケットと一致するかを確認します。 正しいロールを使用していることを確認する […]

 EMRFS S3 最適化コミッターは、Amazon EMR 5.19.0 以降の Apache Spark ジョブで使用可能な新しい出力コミッターです。このコミッターは、EMR ファイルシステム (EMRFS) を使用して Apache Parquet ファイルを Amazon S3 に書き込む際のパフォーマンスを向上させます。この記事では、この新しい最適化されたコミッターを既存のコミッターアルゴリズム、つまり FileOutputCommitter アルゴリズムのバージョン 1 および 2 と比較するためにパフォーマンスベンチマークを実行します。最後に、新しいコミッターに対する現在の制限について検討し、可能な限り回避策を提供します。 FileOutputCommitter との比較 Amazon EMR バージョン 5.19.0 以前では、Parquet を Amazon S3 に書き込む Spark ジョブは、デフォルトで FileOutputCommitter という Hadoop コミットアルゴリズムを使用していました。このアルゴリズムには、バージョン 1 と 2 の 2 つのバージョンがあります。どちらのバージョンも、中間タスクの出力を一時的な場所に書き込むことに依存しています。その後、名前変更操作を実行して、タスクまたはジョブの完了時にデータが表示されるようにします。 アルゴリズムバージョン 1 には、2 つのフェーズの名前変更があります。1 つは個々のタスク出力をコミットするため、もう 1 つは完了/成功したタスクからのジョブ全体の出力をコミットするためです。タスクは名前変更ファイルを直接最終出力場所にコミットするので、アルゴリズムバージョン 2 […]

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。