Dynamic DynamoDBとは

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

Dynamic DynamoDBってなに?

AWSのエバンジェリスト Jeff Barr のブログエントリーを堀内さんが翻訳して掲載してますので詳しくは以下を参照ください。
http://aws.typepad.com/aws_japan/2014/03/auto-scale-dynamodb-with-dynamic-dynamodb.html

わかったこと

  • こんな構成

f:id:yoshidashingo:20140306123316p:plain

  • サンプルではテーブルごとにRead Capacity Unitsのしきい値、Write Capacity Unitsのしきい値、メンテナンスウィンドウを設定するようになってるが、それ以外にも以下で豊富なオプションが確認できる。

http://dynamic-dynamodb.readthedocs.org/en/latest/configuration_options.html

  • メンテナンスウィンドウを設定すると強制的にその時間は変更操作が実行されないようにできる。想定のユースケースが思いつかないけど、1日のうちアクセス数の変化が何度もあるような環境で、あまり設定変更をバタつかせて1日の変更回数上限にひっかからないようにするといった目的で使えるかもしれない。
  • サンプルのCFnテンプレから上記の構成が作れる。
  • サンプルだと制御ノードであるDynamic DynamoDB用EC2インスタンスがオートヒーリング構成になっており、ターミネートしたら勝手に新しいインスタンスが起動されてS3から設定値を読み込んでいた。

CloudFrontでhttpリクエストをhttpsにリダイレクトできるようになった

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

以下のようにAWSブログでアナウンスがありました。

New Features for Amazon CloudFront: Server Name Indication (SNI) and HTTP Redirection | AWS News Blog

2つ目のほうの機能「HTTP Redirection at the Edge」について早速確認。

S3で静的Webサイトをホスティングする。

以下のようなhtmlファイルをバケットに格納し、静的Webサイトホスティングを有効化。
f:id:yoshidashingo:20140306140933p:plain
f:id:yoshidashingo:20140306142252p:plain

CloudFrontを設定する。

こんな感じでDistributionを設定↓
f:id:yoshidashingo:20140306142450p:plain

アクセスしてみる

こんな感じでhttpアクセスしてみると、
f:id:yoshidashingo:20140306142539p:plain
↓↓↓
f:id:yoshidashingo:20140306142613p:plain
httpsにリダイレクトされてました。


今回はS3ホスティングで試しましたが、EC2でWebサイトをホスティングするときも同様です。うちでよく組む構成だと、EC2でWebサイトをホスティングする場合、CloudFrontでSSLをターミナーションして、EC2ではhttpのみで扱うことも多く、EC2側のApacheでhttpsにリダイレクトするような構成ができませんでしたが、この機能を有効にすればhttpでリクエストされても自動的にhttpsにリダイレクトされる構成ができるという点で有効かなと思いました。

RDBMS in the Cloud: Oracle Database on AWS メモ (5) 〜バックアップとリストア〜

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。


AWS クラウドコンピューティング ホワイトペーパー に、AWS で Oracle Database を利用する際のホワイトペーパー「RDBMS in the Cloud: Oracle Database on AWS」が公開されてます。

以下、第5章「Backup and Restore」の訳です。

バックアップとリストア

Oracleデータベースのデプロイ方法に応じて、複数のバックアップ戦略が利用可能である。

Amazon RDS のバックアップとリストア

Amazon RDS の重要なメリットの一つは、バックアップやリカバリのプロセスを自動化できることや、追加のpoint-in-timeリカバリに使えるスナップショットを取得できる点である。バックアップやリカバリに精通しなくてもよく、AWS側にタスクを行わせることができる。

バックアップの自動化

DBインスタンスの自動バックアップがオンになっている場合、Amazon RDS は(バックアップ・ウィンドウ設定時間内に)自動的にデータのフルの日次スナップショットを取得し、DBインスタンスに更新が行えるようにトランザクションログをキャプチャする。自動バックアップは最大35日まで繰り返し設定できる。バックアップ・ウィンドウの間、データのバックアップが完了するまでストレージのI/Oは保留される。このI/Oサスペンション機能はたいていの場合は数分である。Multi-AZのDB配備であればバックアップがスタンバイ・インスタンスから取得されるため、このI/Oサスペンションは発生しない。

Point-in-Timeリカバリーの自動化

バックアップを喪失した場合にデータベースを修復することもできるが、オンプレミスでは複雑になりがちだ。Amazon RDS の自動バックアップ機能では、AWS Management Console や API を通じて point-in-timeリカバリーが可能である。Amazon RDS はデータベースのログ、トランザクションログをバックアップし、ユーザーの指定した保存期間にわたり格納する。これにより保存期間内の特定時点、最短で5分前にDBインスタンスをリストアできる。自動バックアップ保存期間は最大35日間まで設定可能である。

データベース・スナップショット

DBスナップショットはユーザー自身が行うDBインスタンスのバックアップである。これらのフル・データベース・バックアップは明示的に削除するまでは Amazon RDS によって保持され続ける。たとえば必要に応じて、本番データベースと同じ開発環境やテスト環境用のデータベースを作ったり、本番データベースのアップグレードのために、DBスナップショットから新しいDBインスタンスを作成できる。point-in-timeやDBスナップショットからのリストアを行う場合、新しいDBインスタンスは新しいエンドポイントとして作成される点に注意されたい。

Amazon EC2 のバックアップとリストア

Amazon EC2 インスタンス上に Oracle データベースをデプロイする場合、オンプレミスで扱うのと同様にあなた自身でデータベースのバックアップに関する責任を持つ必要がある。

Oracle Recovery Manager (RMAN)

Oracle RMAN(Recovery Manager)はOracle製のバックアップ&リカバリ管理ツールだ。コマンドラインやGUIから操作できる。大半のOracleユーザーはOracle RMANをデータベースのバックアップに利用する。AWSではバックアップの格納場所としていくつかのオプションを提供している。

Amazon S3 へのバックアップ

Amazon Simple Storage Service (Amazon S3) は Amazonのクラウドストレージである。簡潔で権限管理されたWebサービスインタッフェースを用いて、どんな量のデータでも、いつでも、格納、取り出しができる。Amazon S3 は 99.999999999% の耐障害性で設計されており、バックアップの格納先に最適である。格納したAmazon S3のオブジェクトはデータベースと同一リージョン内の複数のアベイラビリティゾーンをまたいだ複数のデバイスに冗長化されて格納される。アベイラビリティゾーンは同一リージョン内で他のアベイラビリティゾーンの障害による影響を受けないようにファシリティが完全に分離された状態で構築されており、それはつまりバックアップを格納しているリージョン内の単一のアベイラビリティゾーンに障害が発生しても、バックアップにはアクセスすることができるということである。格納されたオブジェクトは複数箇所にコピーされることに加え、Amazon S3は定期的にチエックサムを用いて、格納されたデータの整合性を検証する。データの破損が検出された場合は冗長化されたデータを用いて修復がなされる。

Oracle Secure Backup Cloud Module を用いた Amazon S3 へのバックアップ

RMANのメディア管理ライブラリ(MML)であるOracle Secure Backup (OSB) Cloud Module を用いてOracleデータベースを直接Amazon S3にバックアップすることができる。OSB Cloud ModuleはOracle Enterprise Manager Database Control と Grid Control(“Monitoring and Management” の章で後述する)や RMAN CLI を統合してRMANスクリプトのカスタマイズを記述できる。OSB Cloud Module は Oracle Database 11g を含む Oracle Database 9i R2 以降でサポートされている。

Amazon EC2 でデータベースを稼働する際にこの機能を用いる利点は以下である:

  • OSB Cloud Module で Amazon S3 に格納されたバックアップはEC2からアクセスしやすい。バックアップに即座にアクセスできることでデータベースのリストア時間を短縮できる。
  • OSBを利用すると、データのセキュリティのためのバックアップデータの暗号化ができる、またRMANの圧縮機能も使える。
  • Amazon S3を利用することで、非常に手頃な値段で、データベースバックアップのための地理的に冗長化された耐久性の高いストレージを使えることになる。
  • Amazon S3 で事実上無制限の容量を利用できる。

注意:Oracleが提供するAmazon Machine ImagesにはすでにOracle Secure Backup Cloud モジュールがインストールされている。データベースのベースにこのAMIを用いた場合、/home/oracle/scripts/osbws ディレクトリにツールがインストールされている。もし入ってなくても、Oracle Technology Network (OTN) のウェブサイトからダウンロードできる。

EBSボリュームへのバックアップ

“Performance Management”の章で記載したように、Amazon EBSボリュームはインスタンスのライフサイクルから独立して存在できるインスタンスとは別のブロックデバイスであり、直接インスタンスに接続することができる。EBSボリュームにデータベースをバックアップするRMANの使用方法は、オンプレミス環境のディスクバックアップと非常に似ており、前の章で述べた Cloud Backup モジュールを使う方法の代わりにも使える。もう一つの利点はEBSボリュームのバックアップが完了したら AWS Management ConsoleやCLI、APIを用いてスナップショットを作成できる。EBSボリュームのスナップショットは高い耐久性と信頼性の高いデータの格納先として提供されているAmazon S3 に格納される。

EBSスナップショット

データベースがEBSボリュームに格納されている場合は、RMANのバックアップに加え、ほっとバックアップモードに表領域を切替え、基底のAmazon EBSボリュームのスナップショットを取得するとよい。EBSスナップショットは AWS Management Console やCLImAPIから利用可能である。

Amazon Glacier を用いた長期間に渡るアーカイブ

Amazon Glacierは、データのアーカイブやバックアップのための非常にセキュアで高耐久性の高い、非常に低コストなストレージサービスである。Amazon S3 と Glacier には2つの重要な違いがある。

  • Amazon Glacier はS3に比べ非常に安価である。
  • Amazon Glacier はアクセスが頻繁ではなく、取り出しに数時間かかっても構わないデータのために最適化されている。


Amazon S3 と Amazon Glacier は、Amazon S3 にバックアップを格納した一定期間後に、長期間アーカイブ化するたびにAmazon Glacierに自動的に移動するような方法に代表されるように統合がされている。また、Glacier内でどのくらい保管しておくか有効期限を定義しておくこともできる。たとえばS3に15日間(任意で決められるデータベースの復元に使う可能性の最も高い期間)など。15日後、自動的に Amazon Glacierに移動し、1年経過後、Amazon Glacierからも削除する、など。これなら最小限のコストで、古いバックアップを必要に応じて数時間以内に取得できる状態で保管できる。

JAWS-UG四国遍路ツアーに参加してきた #jawsug

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

2/22(土)〜24(月)とJAWS-UG四国遍路に行ってきました。
前日の2/21(金)の香川(うどん県)に参加できなかったのは残念です。きっと次回は伺います。

f:id:yoshidashingo:20140306203420p:plain

日付 勉強会
2/21(金) 香川 2月21日 JAWS-UG うどん県 クラウド勉強会 キックオフ!(香川県)
2/22(土) 愛媛 JAWS-UG愛媛 (日本 Amazon Web Serviceユーザ会愛媛)キックオフ - JAWS-UG愛媛 | Doorkeeper
2/21(金) 高知 2月23日 JAWS-UG 高知 ユーザーズミーティング 第2回(高知県)
2/21(金) 徳島

プレゼン内容

こんなネタでプレゼンしてました。

SIって必要だよね

クラウドは足回りですし、クラウドじゃできないということはもうほとんどありません。
「ビジネスに寄り添えるITの専門家」という持ち場をしっかり守れるSIerであればこの先も需要はなくならないと思ってます。

道後温泉=風呂グラマー(@masuidrive さん)

今回道中、増井さんと一緒だったので、デブサミでプレゼンされた「エンジニアだからできる自由な生き方」を聞かせてもらいました。

デブサミ2014で「エンジニアだからできる自由な生き方」の話をしてきました。 – @masuidrive blog

きっかけ

愛媛(道後温泉)にもJAWS-UGの支部ができることになり、温泉に行くのに「風呂グラマー」に一言お断りしておかないわけにはいかないということで半ば強引に召還させていただきました。

一緒に温泉にも入りましたが、さすがに公衆浴場にはMacBookは持込めませんでしたね、残念。
f:id:yoshidashingo:20140222213700j:plain


100%リモートワークなチーム「デジタルキューブ」

また、道中はデジタルキューブの小賀さんとも一緒でした。デジタルキューブさんは AMIMOTO という AMI を AWS Marketplace で販売している会社です。メンバーは全員リモートで仕事しており、プロ中のプロでお互いにリスペクトし合えてる人しかジョインしてもらわない、営業もなし(100%インバウンドのみ)そんな会社です。

網元起動隊とは何か

ところで小賀さんと言えば WordBench という WordPressコミュニティを日本に根づかせて、1000人規模のイベントを何度もやってます。最近はJAWS-UGの関西方面(だけじゃないけど)でも色々やってくれており、コミュニティに引込まれて人生変わっちゃったって話があれば、糸を引いてるのはだいたいこの人だったりします。
f:id:yoshidashingo:20140306195133j:plain
悪そうな顔してはる...

そんなコミュニティをドライブする名人である小賀さんが今回何やらTシャツを片手に「網元起動隊」という企画をやってました。5分でWordPress環境ができるAMIMOTOを起動して、そんな便利なAMIMOTOを地元で広めてくれる人にTシャツを託すという企画なんですね。もう各支部で入れ食い状態。AMIMOTO/デジタルキューブのブランド力を感じるとともに、やっぱTシャツって優秀なマーケティングツールだなと思った次第です。うちも作ります、チョーかっこいいやつ。
f:id:yoshidashingo:20140306195354j:plain

ゲリラって大切

今回の四国遍路では、網元起動隊員になった人たちが「面白そうだし明日もワゴンに乗って遊びに行っちゃおうかな」と言ってゲリラ的に次の日の勉強会にワゴンに乗って参加してくれました(どうやって帰ったのかはよく覚えてません、みんな大丈夫だったかな)

  • 愛媛→高知:3名
  • 高知→徳島:2名

面白そうな企画を立てて、他人を内輪差よろしく巻き込んで行くのってホントに楽しいですね。
f:id:yoshidashingo:20140306203512j:plain

思ってるより強めに巻き込んでいくってこと

JAWS FESTAをやったときも、来週末に迫ったJAWS DAYSの企画でもしかり、他人を巻き込んで動かしていくときに、お仕事じゃないものをどれだけコミットしてやれる人か、勝手に色々面白いこと考えて、調整して、実践して、強力をあおいで、ってできるかどうかって非常に大事です。

札束でひっぱたけない分、仕事よりコミュニティのほうが大変

小賀さんが「コミュニティ内での動きを見れば、だいたいどんな人間か分かる。金で動いてない以上、より明確に見えてくる」と言ってたのですが、これはほんとに金言です。

JAWS DAYSは来週末だよ

ということで話題に上がったJAWS DAYS、いよいよ来週末です。
今回のワゴンと同じように、前日深夜に全国の拠点から無料バスで集まってきます。

JAWS DAYS 2014

参加登録1200人超えてます、思ってたよりスゴい!!

RDSのdb.m1系もdb.m3系に乗り換えたほうがおトクですよという話

cloudpackエバンジェリストの吉田真吾@yoshidashingo)です。

db.m3系がローンチしてますので、2014/3/5時点の RDS for MySQL(Multi-AZ) のお値段 (Tokyo/オンデマンド) 比較をしてみます。
参照したのは以下の3つのページ

また、RDS for MySQL において PIOPS指定可能な範囲は 1000〜30000(db.cr1.8xlarge のみ 20000 まで実現※30000指定は可能) です。

micro,smallレンジ

タイプ.サイズ vCPU ECU RAM IO性能 PIOPS最適化 時間価格 月額(744h換算) 備考
db.t1.micro 可変 2 0.615GB 低速 - $0.070 $52.08 -
db.m1.small 1 1 1.7 GB 標準 - $0.190 $141.36 -

mediumレンジ

タイプ.サイズ vCPU ECU RAM IO性能 PIOPS最適化 時間価格 月額(744h換算) 備考
db.m1.medium 1 2 3.75 GB 標準 - $0.370 $275.28 m3があるので不要
db.m3.medium 1 3 3.75 GB 標準 - $0.360 $267.84 -

largeレンジ

タイプ.サイズ vCPU ECU RAM IO性能 PIOPS最適化 時間価格 月額(744h換算) 備考
db.m1.large 2 4 7.5 GB 標準 500 Mbps $0.735 $546.84 m3.largeがあるので不要と思いきやm3.largeはPIOPS最適化「なし」という点に留意したい
db.m3.large 2 6.5 7.5 GB 標準 - $0.710 $528.24 -

xlargeレンジ

タイプ.サイズ vCPU ECU RAM IO性能 PIOPS最適化 時間価格 月額(744h換算) 備考
db.m1.xlarge 4 8 15 GB 高速 1,000 Mbps $1.465 $1089.96 m3があるので不要
db.m2.xlarge 2 6.5 17.1 GB 標準 - $1.105 $822.12 -
db.m3.xlarge 4 13 15 GB 高速 Yes(※値不明) $1.420 $1056.48 -

2xlargeレンジ以上

タイプ.サイズ vCPU ECU RAM IO性能 PIOPS最適化 時間価格 月額(744h換算) 備考
db.m2.2xlarge 4 13 34.2 GB 標準 500 Mbps $2.210 $1644.24 -
db.m3.2xlarge 8 26 30 GB 高速 Yes(※値不明) $2.835 $2109.24 -
db.m2.4xlarge 8 26 68.4 GB 高速 1,000 Mbps $4.415 $3284.76 -
db.cr1.8xlarge 32 88 244 GB 10 Gigabit - $9.410 $7001.04 PIOPS最適化「なし」だがEBSまでの帯域はどう確保されるアーキテクチャなのだろうか

わかったこと

  • 基本的にはmedium以上のm1系はm3系に乗り換えたほうがおトク。特にCPUが変わっているためECU値が大きいのでCPUバウンドだったデータベースはすぐにでも乗換を検討したほうがよいかも。
  • db.m3系はPIOPS最適化の帯域値(インスタンス⇔EBS間の帯域)が示されてない。EBSとの帯域についてはそもそもRDSではオプションとして指定するわけではないので、明示する意味あるのか?といったあたり、サービスとして思うところがあるのかもしれない。