Amazon Web Services ブログ

Atlassian JIRA ソフトウェアと Bitbucket データセンターの新しい AWS クイックスタート

AWS クイックスタートは AWS Cloud 内のソフトウェアソリューションのリファレンス実装を迅速にデプロイする場合に役立ちます。クイックスタートを使用すれば、AWS やソフトウェアパートナーが推奨しているベストプラクティスのメリットを活用しながら簡単にソフトウェアをテストしたり使用することができます。

今回は APN アドバンスドテクノロジーパートナー (および DevOps コンピテンシー所有者) である Atlassian と協力して開発したクイックスタートガイドのペアについてご紹介します。このクイックスタートガイドは JIRA ソフトウェアデータセンターAWS 上の Bitbucket データセンターのデプロイで役立ちます。

Atlassian のデータセンターの機能は、規模の大きな開発チームを持ち、スケーラブルで可用性の高い開発ツールとプロジェクト管理ツールを必要とするお客様のために設計されています。こうしたツールは常にミッションクリティカルであるため、堅牢性と耐障害性がベースライン要件であり、実稼働デプロイメントは常にマルチノードまたはクラスター設定で実行されるようになっています。

新しいクイックスタート
JIRA ソフトウェアデータセンターはスピードを必要とするチームにプロジェクト管理ソリューションと問題管理ソリューションを提供、Bitbucket データセンターは Git リポジトリソリューションを提供します。どちらのソリューションも、複数のプロジェクトに携わる規模の大きなチームで可用性が高く大規模なパフォーマンスを実現します。こうした新しい Atlassian クイックスタートにより、徹底的なテストとリファレンスアーキテクチャの完全サポートを利用することができるので、AWS で行う製品のデプロイを大幅に簡略化し加速することが可能になりました。

クイックスタートには、新規または既存の Virtual Private Cloud (VPC) で Bitbucket と JIRA ソフトウェアのデプロイを許可する AWS CloudFormation テンプレートが含まれています。新しい VPC を使用したい場合は、テンプレートが作成できます。同時にパブリックサブネット、プライベートサブネット、NAT ゲートウェイも作成するので、プライベートサブネットで EC2 インスタンスを許可しインターネットに接続することができます (NAT ゲートウェイを利用できないリージョンでは、代わりに NAT インスタンスをテンプレートが作成します)。すでに AWS をご利用されていて適切な VPC がある場合は、代わりに JIRA ソフトウェアデータセンターと Bitbucket データセンターをデプロイすることができます。

起動したい Atlassian 製品の評価版ラインセンスにサインアップしてください。

Bitbucket データセンター
Bitbucket データセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – Bitbucket データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

NFS サーバー – Bitbucket データセンターは共有ファイルシステムを使用して、複数の Bitbucket ノードがアクセスできる一般的な場所にリポジトリを保存します。クイックスタートアーキテクチャはアタッチしている Amazon Elastic Block Store (EBS) ボリュームを使用した EC2 インスタンスで共有ファイルシステムを実装します。

Bitbucket Auto Scaling グループ – Bitbucket データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

Amazon Elasticsearch Service – Bitbucket データセンターはインデックス作成と検索に Elasticsearch を使用します。クイックスタートアーキテクチャは Amazon Elasticsearch Service を使用します。これは AWS クラウドの Elasticsearch でデプロイ、操作、スケールを行いやすくするマネージドサービスです。

JIRA ソフトウェアデータセンター
JIRA ソフトウェアデータセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – JIRA データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

Amazon Elastic File System – JIRA ソフトウェアデータセンターは共有ファイルシステムを使用して、複数の JIRA ノードがアクセスできる一般的な場所にアーティファクトを保存します。クイックスタートアーキテクチャは Amazon Elastic File System を使用する可用性の高い共有ファイルシステムを実装します。

JIRA Auto Scaling グループ – JIRA データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

今後も Atlassian と協力し、この新しいクイックスタートの更新と改善を実現していきます。この他にも Atlassian Confluence と Atlassian JIRA サービスデスクのクイックスタートの作成にも取り組んでおり、AWS re:Invent までにはリリースしたいと考えています。

開始するには Bitbucket データセンタークイックスタートまたは JIRA ソフトウェアデータセンタークイックスタートをご覧ください。また Atlassian のクイックスタートページもご覧ください。テンプレートは今すぐご利用いただけます。ぜひご感想をお寄せください!

Jeff;

AWS オンラインセミナー – 2016 年 10 月 & 11 月(太平洋時間・英語によるセミナー)

AWS による開発事項の最新情報をご存知ですか?Amazon RedshiftAmazon ECSAmazon Cognito について十分理解していますか?IoT について理解し、クラウドのワークロードに適用するセキュリティのベストプラクティスをしっかり把握していますか?EC2 スポット市場を把握し、その活用方法を理解していますか?

トレーニングと教育面に焦点を当てた 10 月と 11 月に開催予定の AWS オンラインセミナーについては次をご覧ください。受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所有時間は 1 時間です。

10 月 25 日

10 月 26 日

10 月 27 日

11 月 8 日

11 月 9 日

11 月 10 日

Jeff;


 
PS – re:Invent 2016 の準備に関するオンラインセミナーをお忘れなく!

X1 インスタンスの更新 – X1.16xlarge + リージョンの追加

今年初旬に AWS は x1.32xlarge インスタンスをリリースしました。約 2 TiB の容量を備えるこのインスタンスタイプは、メモリに大きな負担をかけるビッグデータ、キャッシュ、分析などのワークロードに最適です。AWS のお客様は SAP HANA インメモリデータベース、大規模な Apache Spark や Hadoop ジョブ、様々なタイプのハイパフォーマンスコンピューティング (HPC) ワークロードを実行しています。

そしてこの度、AWS は X1 インスタンスタイプの更新を 2 つリリースしました。

  • 新しいインスタンスのサイズx1.16xlarge インスタンスの新しいサイズはフットプリントが小さいワークロードの実行を可能にします。
  • 新しいリージョン – X1 インスタンスの利用が可能なリージョンを 3 つ追加しました。これでリージョン数は合計 10 になりました。

新しいインスタンスのサイズ
新しい x1.16xlarge の仕様は次のとおりです。

  • プロセッサ: 2 x Intel™ Xeon E7 8880 v3 (Haswell) 2.3 GHz – 32 cores / 64 vCPUs で実行
  • メモリ: Single Device Data Correction (SDDC+1) 使用の 976 GiB
  • インスタンスストレージ: 1,920 GB SSD
  • ネットワーク帯域幅: 10 Gbps
  • 専用の EBS 帯域幅: 5 Gbps (追加料金なしで EBS の最適化)

x1.32xlarge のように、このインスタンスは Turbo Boost 2.0 (最大 3.1 GHz)、AVX 2.0AES-NITSX-NI をサポートします。こうしたインスタンスは、オンデマンドインスタンススポットインスタンスまたは専有インスタンスとしてご利用いただけます。また、リザーブドインスタンスDedicated Host の予約を購入することもできます。

新しいリージョン
X1 インスタンスの両サイズは次のリージョンで利用可能です。

  • US East (Northern Virginia)
  • US West (Oregon)
  • Europe (Ireland)
  • Europe (Frankfurt)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Asia Pacific (Mumbai) – New
  • AWS GovCloud (US) – New
  • Asia Pacific (Seoul) – New

Jeff;

週刊 AWS – 2016 年 10 月 3 日

今回の週刊 AWS の作成には AWS 内外から 20 人の寄稿者にご協力いただきました。自分もぜひ参加していみたいという方は (re:Invent でランチ無料の可能性あり)、GitHub の週刊 AWS をご覧ください。

月曜日

10 月 3 日

火曜日

10 月 4 日

水曜日

10 月 5 日

木曜日

10 月 6 日

金曜日

10 月 7 日

土曜日

10 月 8 日

  • 何もありませんでした。
日曜日

10 月 9 日

新しい AWS Marketplace の製品

新しい & 注目のオープンソース

  • elastic-ci-stack-for-aws は、お客様の VPC で実行中のビルドエージェントのシンプルで柔軟性の高い Auto Scaling クラスターです。
  • aws-lambda-ebs-backups には、EBS ボリュームのスナップショットのバックアップや削除を行うために AWS Lambda サービスを使用して実行する Python スクリプトが含まれています。
  • load-dyno-table は DynamoDB テーブルローダーです。
  • letsencrypt-iam-lambda は受け取った S3 イベントを処理し、AWS IAM の関連する証明書を更新する AWS Lambda 関数です。
  • sundial は依存関係およびスケジューリングを管理する Amazon EC2 Container Service のジョブシステムです。
  • jrestless は AWS Lambda を使用してサーバーレスアーキテクチャで JAX-RS アプリケーションを構築するのに役立つフレームワークです。
  • AWSLambda_CloudFrontMetaData は CloudFront への顧客の訪問からメタデータ (IP バージョン、HTTP バージョン、エッジロケーション) を抽出する Lambda 関数です。
  • hologram は AWS 認証情報を簡単かつ容易に開発者のノートパソコンへ実装します。
  • og-aws は AWS の実践ガイドです。
  • aws-secrets は EC2 インスタンスの秘密情報を KMS 暗号化、IAM ロール、S3 ストレージにより管理するのに役立ちます。

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

AWS ブログのユーザビリティパネル (シアトルまたはリモート)

今後も AWS ブログを通じて読者の皆さんが必要とする情報やエンターテインメントを提供していくため、今月下旬にユーザビリティパネルの開催を企画しています。初心者から上級者まで、ブログの読者や AWS をご利用されているローカル (シアトル) にお住まいの方々はもちろん、リモートからの参加もお待ちしております。ユーザビリティパネルにご参加頂いた方々には、感謝の気持ちを込めて Amazon.com ギフトカードを贈呈いたします。

参加するには今すぐ登録にアクセスしてください。

Jeff;

Snowball HDFS のインポート

オンプレミスで MapReduce を実行していて、HDFS (Hadoop Distributed File System) にデータを保存している場合、中間のステージングファイルを使用することなく、そのデータを直接 HDFS から AWS Import/Export Snowball にコピーできるようになりました。多くの場合、HDFS はビッグデータワークロードに使用されるため、これにより大量のデータを AWS にインポートしてさらに処理するプロセスが簡略化されます。

この新機能を使用するには、最新バージョンの Snowball クライアントを、目的の HDFS クラスターを実行しているオンプレミスホストにダウンロードして設定します。次に、以下のようなコマンドを使用して、Snowball 経由で HDFS から S3 にファイルをコピーします。

$ snowball cp -n hdfs://HOST:PORT/PATH_TO_FILE_ON_HDFS s3://BUCKET-NAME/DESTINATION-PATH

-r オプションを使用して、フォルダー全体を再帰的にコピーできます。

$ snowball cp -n -r hdfs://HOST:PORT/PATH_TO_FOLDER_ON_HDFS s3://BUCKET_NAME/DESTINATION_PATH

詳細については、「HDFS クライアントの使用」を参照してください。

Jeff;

※AWS Import/Export Snowballは日本で未提供のサービスです。

新しい collectd の CloudWatch プラグイン

これまでご自分のビジネス、アプリケーション、システムメトリックスを Amazon CloudWatch で保存されてきたと思います (詳しくは「Amazon CloudWatch の新しいカスタムメトリックス」をご覧ください)。随分前のことになりますが、私が 2011 年に書いたブログで「ユーザーの AWS リソースを CloudWatch で保存しているように、グラフを表示したり、アラームを設定、自動化したアクションをこうしたメトリックスに基づいて設定することができます。」といったように、この機能についてご紹介したことがあります。

そして本日より、新しい CloudWatch プラグイン collectd 対象を使用することで、ユーザーのシステムから統計を収集する方法を簡略化しながら収集した情報を CloudWatch に保存できるようになりました。さまざまなタイプの統計を収集する collectd の機能と、保存、表示、アラート、警告を可能にする CloudWatch の機能を組み合わせることで、EC2 インスタンスの状態とパフォーマンス、そして EC2 で実行しているオンプレミスハードウェアやアプリケーションについてより細かく把握することができます。このプラグインはオープンソースプロジェクトとしてリリースしています。皆様からのプルリクエストをお待ちしております。

パフォーマンスと可搬性を提供するため collectd デーモンは C で記述されています。これは 100 以上のプラグインをサポートし、ApacheNginx ウェブサーバーパフォーマンス、メモリ使用量稼働時間の統計を収集できるようにします。

インストールと設定
実際のアクションを見るため、collectd と新しいプラグインを EC2 インスタンスにインストールして設定してみました。

まず、CloudWatch にメトリックスデータを書き込むためのアクセス許可を使用して IAM ポリシーを作成します。

次にポリシーで EC2 を許可する IAM ロール (インスタンスで実行する collectd コード) を作成します。

オンプレミスサーバーから統計を収集するためにプラグインを使用する予定の場合や、すでに EC2 インスタンスを実行している場合は、このステップを行わずに適切なアクセス権限を代わりに使用して IAM ユーザーを作成します。私の場合、最初の例ではなくこの方法を実行していたら、ユーザーの認証情報をサーバーまたはインスタンスに追加する必要がありました。

ポリシーとロールの準備ができたら、EC2 インスタンスを起動してロールを選択します。

ログインを完了し collectd をインストールします。

$ sudo yum -y install collectd

次にプラグインを取得しスクリプトをインストールします。スクリプトを実行可能にしたら、それを実行します。

$ chmod a+x setup.py
$ sudo ./setup.py

いくつかの質問に答えた後、問題なく設定を実行できました。collectd は設定完了後に起動しました。

Installing dependencies ... OK
Installing python dependencies ... OK
Copying plugin tar file ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
  1. Automatic [us-east-1]
  2. Custom
Enter choice [1]: 1

Choose hostname for published metrics:
  1. EC2 instance id [i-057d2ed2260c3e251]
  2. Custom
Enter choice [1]: 1

Choose authentication method:
  1. IAM Role [Collectd_PutMetricData]
  2. IAM User
Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK
$

collectd を実行することができ、プラグインのインストールと設定が完了したら、次のステップは目的の統計を決定し、CloudWatch に発行するプラグインを設定することです (メトリックスごとに料金が発生するので、これは大切なステップです)。
ファイル /opt/collectd-plugins/cloudwatch/config/blocked_metrics には、収集したメトリックスのリストが含まれていますが、これは CloudWatch に発行されていません。

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
memory--memory-used
load--load-
memory--memory-buffered
memory--memory-cached

メモリの消費量が気になっていたので、次のラインを追加しました。 /opt/collectd-plugins/cloudwatch/config/whitelist.conf:

memory--memory-.*

collectd の設定ファイル (/etc/collectd.conf) には collectd とプラグインの設定も含まれています。私の場合、変更の必要はありませんでした。

変更を反映させるため、collectd を再起動させました。

$ sudo service collectd restart

多少のメモリを消費させるためにインスタンスを少し使用してから、CloudWatch コンソールを開きメトリックスを探し表示しました。

このスクリーンショットには、今後 CloudWatch コンソールに施される強化点のプレビューが含まれていますので、ご自分の画面に同じものが表示されなくてもご安心ください (詳しくは今後お知らせします)。

プロダクションインスタンスをモニタリングしていたのであれば、collected プラグインを 1 つ 2 つインストールすることもできました。Amazon Linux AMI で利用可能なリストは次をご覧ください。

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main
collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main
collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main
collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main
collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main
collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

主要事項
バージョン 5.5 以降の collectd を使用している場合は、4 つのメトリックスがデフォルトで発行されるようなりました。

  • df-root-percent_bytes-used – ディスク速度
  • memory–percent-used – メモリ使用量
  • swap–percent-used – スワップ使用率
  • cpu–percent-active – cpu 使用率

これらを発行したくない場合は whitelist.conf ファイルから削除することができます。

現在、Amazon Linux AMI、Ubuntu、RHEL、CentOS のプライマリリポジトリは古いバージョンの collectd を提供しています。カスタムリポジトリからインストールした場合またはソースから構築した場合はデフォルト設定による動作が異なる点にご注意ください。
その他
ご紹介できるものは他にもあるのですが、残念ながら時間切れです。その他のプラグインもインストールし whitelist.conf を設定してさらに多くのメトリックスを CloudWatch に発行することができます。CloudWatch アラームを作成してカスタムダッシュボードやその他を設定することもできます。

始めるには GitHub の AWS ラボにアクセスし collectd の CloudWatch プラグインをダウンロードしてください。

Jeff;

IPv6 サポートの更新 – CloudFront、WAF、S3 Transfer Acceleration

先日のブログ「Amazon S3 で IPv6 をサポート」の続報として、今回は Amazon CloudFrontAmazon S3 Transfer AccelerationAWS WAF と 50 か所以上に渡るすべての CloudFront エッジロケーションでも IPv6 サポートが利用可能になったことをお知らせします。AWS では、すべての自律システムネットワーク (ASN) で IPv6 を有効にするための段階的な移行プロセスを本日より開始し、今後数週間に渡りすべてのネットワークで拡張する予定です。

CloudFront IPv6 のサポート
Amazon CloudFront ディストリビューションごとに IPv6 サポートを有効にすることができます。IPv6 を使用して CloudFront エッジロケーションに接続する閲覧者とネットワークは自動的に IPv6 でコンテンツを取得します。IPv4 を使用して接続する場合は以前のように機能します。オリジンサーバーへの接続には IPv4 を使用します。

新たに作成したディストリビューションでは自動的に IPv6 が有効になります。既存のディストリビューションを変更するには [Enable IPv6] を有効にします。これはコンソールまたは CloudFront API から設定できます。

この新機能の重要事項については次をご覧ください。

  • エイリアスレコード – ディストリビューションで IPv6 サポートを有効にすると、ディストリビューションの DNS エントリは AAAA レコードを含むものに更新されます。Amazon Route 53 とエイリアスレコードを使用してディストリビューションのドメインすべてまたは一部をマップしている場合、そのドメインに AAAA エイリアスを追加する必要があります。
  • ログファイルCloudFront アクセスログを有効にしている場合、IPv6 アドレスが c-ip フィールドで表示されるので、ログ処理システムがそれに対処できるようにしておいてください。
  • 信頼された署名者信頼された署名者と IP アドレスのホワイトリストを併せて使用している場合は、IP ホワイトリストと実際のコンテンツの IPv4/IPv6 ディストリビューションを備える、信頼された署名者 URL の IPv4 に限られたディストリビューションの使用を強くお勧めします。このモデルでは、IPv4 アドレスを使用して送信した署名リクエストにサインしたことで、コンテンツのリクエストがホワイトリストに載っていない別の IPv6 アドレスから届くといった問題を回避することができます。
  • CloudFormation – CloudFormation サポートを準備中今回のリリースでは、CloudFormation テンプレートから作成したディストリビューションで IPv6 は有効になりません。既存のスタックを更新する場合、スタックで参照したディストリビューションの設定に変更はありません。
  • AWS WAFAWS WAF と CloudFront を併せて使用している場合は、IPv6 アドレスのホワイトリストまたはブラックリストで適切となるように WebACL と IP ルールセットを必ず更新してください。
  • Forwarded ヘッダー – ディストリビューションで IPv6 を有効にする場合は、オリジンに渡した X-Forwarded-For ヘッダーに IPv6 アドレスが含まれているようにしてください。オリジンがこの形式のヘッダーを処理できるか確認してください。

詳しくは「Amazon CloudFront で IPv6 をサポート」をご覧ください。

AWS WAF IPv6 サポート
AWS WAF はアプリケーションレイヤーで発生する攻撃からアプリケーションを保護します (詳しくは「新機能 – AWS WAF」をご覧ください)。

AWS WAF が IPv4 アドレスまたは IPv6 アドレス経由で届くリクエストを調べられるようになりました。IPv6 と一致するウェブ ACL を作成することができます。詳しくは「IP Match Conditions の使用」をご覧ください。

既存の WAF 機能はすべて IPv6 に対応、そのパフォーマンスで目に見える変化はありません。IPv6 は WAF が収集し表示したサンプルリクエストで表示されます。

S3 Transfer Acceleration IPv6 サポート
この重要で新しい S3 機能が IPv6 をサポートするようになりました (詳しくは「AWS ストレージの更新 – Amazon S3 Transfer Acceleration + より多くのリージョンでさらに大きくなった Snowballs」をご覧ください)。アップロードに使用できるデュアルスタックのエンドポイントに簡単に切り替えることができます。次のように変更するだけです。

https://BUCKET.s3-accelerate.amazonaws.com

https://BUCKET.s3-accelerate.dualstack.amazonaws.com

クライアントオブジェクトの作成とデュアルスタック転送の有効を可能にする AWS SDK for Java 使用コードは次の通りです。

AmazonS3Client s3 = new AmazonS3Client();
s3.setS3ClientOptions(S3ClientOptions.builder().enableDualstack().setAccelerateModeEnabled(true).build());

大半のアプリケーションとネットワークスタックは自動的に IPv6 の使用を好む傾向があるので、これ以上の設定は必要ありません。IPv6 アドレスと併せて使用する上で機能動作に問題がないことを確認するため、パケットの IAM ポリシーを見直すことをお勧めします。詳しくは「IPv6 を使用して Amazon S3 にリクエストを送信」をご覧ください。

テストを忘れずに
AWS リージョンへの IPv6 接続に制限があったり存在しない場合は、代わりに IPv4 が使用されます。以前公開したブログでも触れましたが、IPv6 をサポートするようにクライアントシステムを設定することができます。ただし、その場合は IPv6 パケットをインターネットにルートするように設定していないネットワークに接続する必要があります。こうした理由から、IPv6 に切り替える前に何らかのアプリケーションレベルで行うエンドツーエンド接続のテストを行うことをお勧めします。

Jeff;

Amazon Game Studios が新ゲームタイトル「Breakaway」を発表

Amazon Game Studios (AGS)は今年のTwitchConで新しいゲームタイトル「Breakaway」を発表しました。Breakawayは高速アクション、チームワークとライブストリーミング用に構築された神話をモチーフにした対戦アクションゲームです。AGSはまた、Twitchのために作成されたStream+, Twitch Metastream, Broadcaster Match Builder, Broadcaster Spotlight等の新機能を発表しました。

Breakawayについてもっと詳しく知りたければ、playbreakaway.com の確認と Twitterの@PlayBreakaway のフォローをお願いします。

翻訳はSA 森が担当しました。原文はこちらです。

AWS Lambda と Amazon API Gateway で Express アプリケーションを実行

ExpressNode.js のウェブフレームワークです。これを使用すると、「サーバーレス」ウェブサイトやウェブアプリケーション、API を簡単にデプロイできます。サーバーレス環境では、大方またはすべてのバックエンドロジックがステートレスのオンデマンドで実行します (詳細情報については Mike Roberts によるブログ「Serverless Architectures」をご覧ください)。今月初旬に公開したブログ (「API Gateway の更新 – API 開発を簡素化する新機能」) で紹介した新しい Amazon API Gateway 機能と AWS Lambda を併せて使用した場合、既存の Express アプリケーションをサーバーレスで実行することができます。API Gateway を使用すると API を中心に開発者のエコシステム構築を可能にする使用量プランなど追加機能を利用したり、キャッシュにより応答性と費用対効果に優れたアプリケーション構築を行うこともできます。

AWS は aws-serverless-express パッケージを提供することで Express アプリケーションから LambdaAPI Gateway への移行をお手伝いしています。このパッケージには実例が含まれています、ぜひご活用ください。

Express コードとアプリケーションを API GatewayLambda に移行する場合に利用できる 2 つのリソースをご紹介します。

Jeff;