プログラマでありたい

おっさんになっても、プログラマでありつづけたい

AWS Route53を使って、はてなダイアリーから、はてなブログに独自ドメインを設定した話

 自分ブランディングしていきたいということで、はてなダイアリーを卒業することにしました。自分ブランディングとは、単に独自ドメインを取得して、そのドメインの価値を上げるというそれだけのことです。さて、実際どうしたのか。悩んだ末に、結局はてなブログの有料版にして、独自ドメインの設定をしているのみです。はてなからの卒業ならずです。

 

 最初の選択肢としては、世界の網元(AMIMOTO) + StaticPress + S3WebHostingを検討していました。しかし旧ブログの流入量を捨てるのは勿体無いので、はてなダイアリーから301リダイレクトしてくれる、はてなブログを選びました。色々ごめんなさい。

 

移行手順


 さて、移行すると決めたので、空いている時間を見つけて一気にやってしましました。手順としては、以下のとおりです。

  1. ValueDomainでドメインの取得
  2. AWSのRoute53でHosted Zoneの設定
  3. ValueDomainのNameServerをRoute53で与えられたNameServerに変更
  4. はてなブログの開設
  5. プライベートモードで、はてなダイアリーからはてなブログに移行
  6. はてなブログ移行後に、テーマなどのデザインの調整
  7. はてなブログの設定->詳細設定に、独自ドメインの設定
  8. AWSのRoute53にCNameでレコードセットを作成
  9. はてなブログの設定->詳細設定で、「ドメイン設定をチェック」
  10. はてなブックマークの移行と記事のリダイレクトの設定

 ハマったのが、7〜9です。7でblog.takuros.netと設定後、CNameで設定してくださいと出てきます。Route53の方で設定するのですが、設定する値がはてなブログのOriginのURLである、「dkfj.hatenablog.com」ではなく、「hatenablog.com」という値ということ。これは説明ちゃんと読んでなかったのですが、全てのリクエストをhatenablog.comに振り分けた上で、はてなの方で独自ドメインかはてなブログのOriginのURLに振り分ける仕様のようです。

 次に、「ドメイン設定をチェック」。これが何度やっても「ドメインの設定状況: エラー レコードが見つかりませんでした」しか出てきません。digやnslookupで確認しても、ちゃんと想定通りの値を返します。さっぱり解りません。サポートに連絡するも、土日なので翌営業日以降の対応ということで、未だに回答は貰っていません。数時間後に再度やってみると、何事もなくチェックが通りました。結構、謎です。後のトラブルで、何となく原因が推測できたので、後述します。

 独自ドメインの設定が終わったので、最後にブックマークとリダイレクトの設定をしてお終いです。1000記事以上でしたが、移行自体は非常に簡単に終了しました。なかなか良く出来ていると思います。移行後のデザイン崩れも、それ程なかったです。

 

ValueDomain+Route53の設定例


 Hosted ZoneでNameServerの一覧を取得したら、ValueDomainのNS設定をします。

f:id:dkfj:20140330164514p:plain

 

 

 

 NameServerの切り替わりを、nslookup等で確認できたら、CNameの設定をおこないます。

 

f:id:dkfj:20140330164522p:plain

独自ドメインのトラブル


 独自ドメインに移行後に、3度ほど独自ドメインではなくはてなブログのOriginのURLに切り替わっているということがありました。設定画面を確認すると、ドメインの設定状況がエラーになっています。理由は、現時点でも謎です。

f:id:dkfj:20140330164518p:plain

 

 

 はてなブログの方では、定期的にドメインのチェックをしている模様です。その際に失敗すると、独自ドメインではなくOriginのURLに変更するようです。推測ですが、はてな側からのドメインチェックはTTLやらをみてゴニョゴニョしてるのではと思います。それが短すぎると、何らか悪影響があるのかもしれません。移行前の最初期はTTLを300秒に設定し、それでもドメインチェックでエラーが出続けるので60秒に設定の上で色々試していました。成功した後も、様子見のためにそのまま60秒にしていたのですが、この設定のままだと頻繁にエラーが出て切り替わりが行われます。もしかしてと思って、TTLを1時間にしてみたところ、12時間ほど経過しましたがドメインチェックのエラーは発生していません。単純に、はてな側のドメインチェックは高確率でエラーが発生し、TTLの都度行うような仕様なのかもしれません。誰か教えてください。

 

はてなブログに移行して


 割と快適です。まだ試していないですが、MarkDown記法が使えるので今後はそれで書く予定です。またJavaScriptに対する自由度やGoogleのSiteMasterツールも使えるようになっています。また時間を見つけて、順次設定していこうと考えています。不満としては、デザインテンプレートが、どれもメインの文章欄の幅が狭いことです。出来れば、画面一杯に使えるのが欲しいですね。(サイドメニュー付きで)

 

パソコンで作業する際は、ポモドーロ・テクニック(Pomodoro Techinique)を使うとよい

 


 最近、パソコンで執筆作業をしています。しかし、パソコンで作業すると調べ事のついでに、関係ないサイトとか閲覧して気が付くと全然進んでいないとということが多々あります。これでは駄目だと試してみたのが、ポモドーロテクニック(Pomodoro Technique)です。ポモドーロテクニックとは、時間を25分と5分に分けて作業することです。。25分のほうを1ポモドーロとしてタスクを割り振り、5分のほうを休憩時間とします。要は25分集中して仕事をし、5分休憩するの繰り返しです。そして4ポモドーロをこなすと30分程休憩するという方式です。ちなみに、ポモドーロはイタリア語でトマトです。考案者のFrancesco Cirillo氏が、トマト型のキッチンタイマーを使っていたのが始まりのようです。


 すごく単純なのですが、これが意外に作業効率がかなりアップします。パソコンで作業していると、前述の通りタスクと休憩の境目が曖昧になります。ちょっと休憩のつもりや調べごとのついでに、延々とTwitterやFacebook、ブログなど見続けることもあります。その時に画面の端っこにポモドーロ・タイマーを置いておくと、タスクの時間と休憩の時間をハッキリと意識できます。ブログとか見るのは、休憩時間の5分だけと決める、それだけで効率が数倍にアップします。(単純にサボり過ぎていたということに気がついただけですが。。。)


 さて、実践方法です。自宅の場合は、キッチンタイマーを用意するというのも1つです。しかし、公共の場だと音がなるものは、難しいでしょう。どこでも出来るお勧めの方法としては、パソコンにタイマーを常駐させる方法です。WindowsにしろMacにしろ、Pomodoroで検索すると幾らでも有料・無料を問わず出てきます。気に入ったのを1つ試すとよいでしょう。


 私は、PomodoroAppというのを使っています。恐ろしくシンプルで、25分と5分のタイマーがあって、画面に常駐するだけです。簡単に自分で作れそうですが、結構気に入っています。


 ついついサボっちゃうという人は、騙されたと思って試してみてはいかが?

PomodoroApp

PomodoroApp

  • Chi Chiu Tang
  • 仕事効率化
  • ¥200

 

Capybara-DSLのはなし

 ちょっとCapybaraについて、整理する必要があったのでこちらで簡単にまとめておきます。Capybaraは、Githubのスタートページに使い方が丁寧に書いているので、そちらを参照したら大抵のことが解るようになっています。

What is Capybara



 Capybaraは、Webアプリケーションのインテグレーション・テストを補助する為のライブラリです。Capybaraが提供する本質的な機能としては、DSLとDriverの2点のみです。DSLとはドメイン固有言語で、特定の問題に特化したコンピュータ言語です。Capybaraはテスティングフレームワークを操作する命令を、それぞれのフレームワークに依存しない形で提供します。つまり、テスティングフレームワークであるCucumberやRSpec,Test::Unitなどを透過的に利用できます。次にドライバーです。Webアプリケーションのインテグレーション・テストには、ブラウザもしくはそれに類するものが必要です。その為に、Seleniumのようにブラウザを操作するフレームワークや、WebKitのようなブラウザのレンダリングエンジンを直接使う方法があります。Capybaraは、それらをドライバとして扱うことが出来ます。

CapybaraのDSL



 Capybaraには、下記の機能をDSLとして提供しています。要は、CucumberであろうがRSpecであろうが、同じように扱えるところがメリットです。一方で、CucumberからRSpecに乗り換えるという要件もあまりないので、どう考えるべきなんでしょうね。

画面遷移機能

 Capybaraの画面遷移は、GETメソッドのみです。POSTについては、フォーム入力機能を利用します。

メソッド名 機能
visit GETでページ遷移します。カレントのパスは、current_pathで取得できます。
リンク&クリック機能

Capybaraは、一通りのフォームの入力機能が用意されています。

メソッド名 機能
click_link('id-of-link') ID指定でリンクを押します
click_link('Link Text') リンクのテキスト名で押します
click_button('Save') ボタン名で名前を押します
click_on('Link Text') リンクかボタンどちらかをクリックします
click_on('Button Value') ボタンの値指定で押します
フォーム入力機能

Capybaraは、一通りのフォームの入力機能が用意されています。

メソッド名 機能
fill_in('First Name', :with => 'John') フォームテキストを埋めます
fill_in('Password', :with => 'Seekrit') パスワードフォームを埋めます
fill_in('Description', :with => 'Really Long Text...') TextAreaを埋めます
choose('A Radio Button') ラジオボタンを選択します。
check('A Checkbox') チェックボタンを選択します。
uncheck('A Checkbox') チェックボタンの選択を外します
attach_file('Image', '/path/to/image.jpg') 画像を添付します
select('Option', :from => 'Select Box') セレクトボックスを選択します
クエリー機能(確認機能)

Capybaraではクエリー機能を利用して、テストを行います。

メソッド名 機能
page.has_selector?('table tr') エレメントの存在確認をします
page.has_selector?(:xpath, '//table/tr') XPath指定で、エレメントの存在確認をします
page.has_xpath?('//table/tr') XPath指定で、エレメントの存在確認をします
page.has_css?('table tr.foo') CSSで、エレメントの存在確認をします
page.has_content?('foo') 文字列の存在確認をします
検索機能

検索機能としては、find_field,find_button,find,allの4つがあります。

メソッド名 機能
find_field('First Name').value フィールド名指定で検索し、値を表示します
find_link('Hello').visible? フィールド名指定で検索し、表示有無を確認します
find_button('Send').click ボタンを検索し、クリックします
find(:xpath, "//table/tr").click XPath指定で検索し、クリックします
find("#overlay").find("h1").click 入れ子で検索し、クリックします
all('a').each { |a| a[:href] } 全ての要素からaタグを抽出し、hrefを表示します
スコープ機能

 スコープ機能を利用することで、特定のエレメント下のみ操作できます。ループ処理等で便利です。

within("li#employee") do
  fill_in 'Name', :with => 'Jimmy'
end

within(:xpath, "//li[@id='employee']") do
  fill_in 'Name', :with => 'Jimmy'
end
スクリプティング機能(JavaScriptのサポート)

 CapybaraはJavaScriptをサポートしています。ただし、使用中のDriverがJavaScriptをサポートしていることが前提です。(O.K. Selenium,WebKit,Poltergeist NG RackTest)

メソッド名 機能
page.execute_script("$('body').empty()") JavaScriptを実行します
デバッグ機能

 デバッグ用に幾つかの機能が提供されています。テストのエビデンスにも活用出来るのでは。(テストの再現性を確保したら、そもそもエビデンス不要ですがね。)

メソッド名 機能
save_and_open_page スクリーンショットを取得します
print page.html ページの印刷します
page.save_screenshot('screenshot.png') スクリーンショットを取得します

CapybaraのDriver



 Capybaraには、Driverとして幾つかのブラウザシミュレータやブラウザエンジンを扱うことが出来ます。使い分けとしては、JavaScriptを利用しないものについては、RackTestのような軽量のものを利用することが考えられます。また、開発段階は、Seleniumを使って実際の動きを見て、退行テストの段階になったときはWebKitを使い軽量化するなども考えられます。下記のように、簡単にDriverを変更できます。

Capybara.default_driver = :selenium
Driver名 特徴
RackTest デフォルトのDriverです。JavaScriptはサポートしていません。また、外部のURLへのアクセスも出来ません。
capybara-mechanize RackTestと同様にJavaScriptはサポートしていません。しかし、外部のURLへのアクセス可能です。
Selenium Capybaraは、Selenium 2.0(WebDriver)をサポートしています。またJavaScriptをOnにした場合は、指定しないと自動的にSeleniumを利用します。
Capybara-webkit headlessを利用して画面なしでテストします。レンダリングエンジンとしては、WebKitを利用しJavaScriptのテストが可能です。Xvfbが必要です。
Poltergeist headlessを利用して画面なしでテストします。PhantomJSが動作しJavaScriptのテストが可能です。Xvfbが不要です。


 サーバにXvfbのインストールは、割と面倒くさいです。継続的インテグレーションの為にサーバサイドでテストを実行したい場合は、Poltergeistがよいかもしれません。本格的にやるのであれば、Seleniumを利用して、複数のブラウザに対してテストを実行するといったこともよいですね。

まとめ



 Capybaraの役割が解れば、なかなか便利です。私の場合は、SeleniumやCucumber,RSpecを使ってからCapybaraを使いだしました。いきなりCapybaraの方が学習コストが低くてよいかもしれません。一方で、ハマった時によくわからないというのもあるかもしれません。何はともあれ、一度お試しください。Enjoy!!


See Also:
Web画面の自動テストの導入に失敗する理由とその対策
Selenium2.0 WebDriverで複数ブラウザのUIテスト もう一度、Selenium再入門
JenkinsとSelenium WebDriverでUI層のテストも自動化&永続化する


参照:
jnicklas/capybara

Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き

 諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。

ELBの内部構造



 ELBは、ELBエンドポイントとELBインスタンス(仮称)によって構成されます。ELBインスタンス(仮称)の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.comのようなDNS名を持ちます。このELBのDNS名を名前解決すると、ELBインスタンスのグローバルIPが返されます。ELBインスタンスが複数ある場合は、複数のIPを返します。ELBインスタンスは、利用するAZに少なくとも1つ存在します。MultiAZ構成の場合であれば、少なくとも2つのIPが返されます。
 クライアントからアクセスがあった場合は、DNSのラウンドロビンでELBインスタンスのIPアドレスが返されます。ELBインスタンスは、配下のインスタンスに振り分けられます。恐らくELBインスタンス内にリバースプロキシのような機能があるのでしょう。

 nslookupとdigをすると、次のようになります。

$ nslookup ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com 
Server:		192.168.11.1
Address:	192.168.11.1#53

Non-authoritative answer:
Name:	ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
Address: 54.250.186.157
Name:	ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
Address: 54.199.196.182
$ dig ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.8.5-P1 <<>> ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1343
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. IN	A

;; ANSWER SECTION:
ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. 48	IN A 54.199.196.182
ELB-Test-869539816.ap-northeast-1.elb.amazonaws.com. 48	IN A 54.250.186.157

;; AUTHORITY SECTION:
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-54.awsdns-06.com.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-1683.awsdns-18.co.uk.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-982.awsdns-58.net.
ap-northeast-1.elb.amazonaws.com. 166 IN NS	ns-1325.awsdns-37.org.

;; ADDITIONAL SECTION:
ns-54.awsdns-06.com.	166659	IN	A	205.251.192.54
ns-982.awsdns-58.net.	166660	IN	A	205.251.195.214
ns-1325.awsdns-37.org.	166660	IN	A	205.251.197.45
ns-1683.awsdns-18.co.uk. 166660	IN	A	205.251.198.147

;; Query time: 24 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Tue Feb 11 16:45:22 JST 2014
;; MSG SIZE  rcvd: 301

ELBのスケーリング



 一定以上の負荷が掛かりELBの処理能力を上げる必要が出た場合に、自動的にELBのスケールアップもしくはスケールアウトが行われます。このELBのスケーリングも、DNSの名前解決を利用して行います。スケールアップの場合は、より処理能力の高いELBインスタンスを立ちあげてIPに切り替えます。スケールアウトの場合は、同等の処理能力のELBインスタンスを立ちあげてIPアドレスに追加します。いずれにせよIPアドレスが変わるのでご注意ください。
 ちなみにスケールアウトかスケールアップのどちらを選ぶのかは、AWSが自動的に選択します。そのアルゴリズムは公開されていません。想像ですが、トラフィック数が多い場合はスケールアウト、リクエスト辺りのトラフィック量が多い場合はスケールアップを選ぶのではないでしょうか?全くの想像なので、いつか試してみたいです。

障害時の動作



 障害時の動作も、基本的にはDNSを利用します。ELBインスタンス配下のインスタンスが全滅した場合、そのELBインスタンスのIPアドレスは削除されます。そのIPアドレスが最後の1つの場合は、そのまま残ります。ELBインスタンス自身の障害の際も、DNSの切り替えで対処します。

ELBのCloudWatchのMetrics



 ついでにELBのCloudWatchのメトリクスを見てみましょう。

メトリクス名 概要
HealthyHostCount ELB配下の正常稼働している(healthy)インスタンス数です
UnHealthyHostCount ELB配下の異常稼働している(unhealthy)インスタンス数です
RequestCount ELBで処理されたリクエスト数です。HTTPCode_Backend_XXXの合計です
Latency ELBからバックエンドインスタンスに渡されて返ってくるまでの時間です
HTTPCode_ELB_4XX
HTTPCode_ELB_5XX
ELB自身が返すステータスコードです
HTTPCode_Backend_2XX
HTTPCode_Backend_3XX
HTTPCode_Backend_4XX
HTTPCode_Backend_5XX
ELB配下のバックエンドインスタンスで生成されたレスポンスコードです
SurgeQueueLength ELBで処理待ちの待ち行列(surge queue)の数です
SpilloverCount 待ち行列(surge queue)から溢れたリクエスト数です

 ポイントとしては、SurgeQueueLength及びSpilloverCountをみておけば、ELBで処理出来なかったリクエストが解るという点でしょうか。あとは、HTTPCode_ELB_5XX系のHTTP 503: Service Unavailableなどを見ていれば、ELBのキャパオーバ等の検出も出来る可能性があります。
 Amazonさん、ついでにELBの流量を監視するメトリクスも作ってくれませんかね?

まとめ



 公開されている資料の中でのELBの動作をまとめてみました。もしかしたら誤解している部分があるかもしれませんので、その際は是非ご指摘ください。ちなみにこのELBの動作のように、DNSを切り替えて行うというのはAWSの基本思想だと思います。他のサービスも色々利用していますし、たぶんそうなんだろうなぁというところもあります。Googleのクラウド(Google Cloud Platform)はまた違ったように見受けられるので、そのうち調べて対比させてみたいと思います。


See Also:
AWSのEBS Provisioned IOPSからEBSについて妄想する
結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について


参照:
AWSマイスターシリーズ Amazon Elastic Load Balancing (ELB)
Elastic Load Balancing 開発者ガイド
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services
Monitor Your Load Balancer Using Amazon CloudWatch - Elastic Load Balancing

プラレール・レイアウト・パターンその2。交差ポイントレールの活用

 どの辺りの層に需要があるのか解りませんが、大好評だったプラレール・レイアウト・パターンの第二弾です。前回の反響が大きかったので、わざわざ交差ポイントレールを買い直してこの記事を書くことにしました。交差ポイントレールを買い直した理由は、終わりの方を読んでください。ちなみにレールの買い増しを続けることにより、我が家のプラレールの収納場所の限界と、嫁さんへの理由付けに苦慮しております。何か良いアイデアがあれば教えて下さい。
 さて、交差ポイントレールですが、これを使えば狭い面積でループが出来るので重宝します。また、直交とカーブの設定が出来るので、組み合わせによりパターンを増やせます。基本的なパターンを2つ程あげてみます。

最小八の字パターン



 交差ポイントレールの基本パターン、八の字レイアウトです。交差ポイントレールを使うことで、最小構成で8の字レイアウトを作れます。8の字レール(L+R)と違って、どちらのループにも入るところが秀逸です。


【プラレール】最小八の字レイアウト


構成
1/2直線レール 4本
曲線レール 12本
交差ポイントレール

交差ポイントを利用した折り返しパターン



 交差ポイントと8の字レール、Uターンレールを組み合わせて、左右のレールを交互に行き来するパターンです。Uターンレールで折り返すことにより、毎回8の字ポイントレールのポイントが切り替わります。その結果、左右のループを交互に行き来します。交差ポイントを使うことにより、省スペースで直交を実現出来ます。


【プラレール】交差ポイントを利用した折り返しレイアウト


構成
1/2直線レール 3本
曲線レール 10本
8 の字ポイントレール(L)
Uターンレール
単線・複線ポイントレール
交差ポイントレール

ニュー坂レールを使った折り返しパターン



 交差レールとの対比の為に、ニュー坂レールを使った折り返しのパターンを見てみましょう。構成は大きくなりますが、交差レールを使った折り返しパターンと同じ動きをします。この違いをみれば、平面的に直交を作れる交差レールの可能性が解ると思います。


【プラレール】ニュー坂レールを使った折り返しレイアウト



構成
1/2直線レール 12本
直線レール 1本
曲線レール 8本
8 の字ポイントレール(L)
Uターンレール
単線・複線ポイントレール
ニュー坂レール
交差ポイントレール

まとめ



 今回は、交差ポイントレール素晴らしいよという話でした。直交とカーブのどちらも選べるという所が、使い勝手が良い点です。ただし、一点だけ注意が必要です。交差ポイントレールの黄色いポイント部分は、何故か簡単に外れせます。小さい子供は、外して喜びますのでご注意ください。我が家の初代の交差ポイントレールは、1歳当時の息子にポイントを外されて噛まれてダメになりました。誤飲の危険もありますので、くれぐれもご注意を。


See Also:
プラレールの電池に、ダイソーの単三電池とパナソニック。あるいはアマループ
プラレール・レイアウト・パターン。折り返し編

JAWS-UG Osaka 第10回勉強会に行ってきましたよ

 1月30日に開催されたJAWS-UG Osaka 第10回勉強会に参加して、少し喋ってきました。当日の発表内容や雰囲気については、MINAMI ENGINEさんのまとめとTogetterを見て頂ければと思います。


 当日、細かい数字をそのまま載せておいたので、絶対見えないだろうなということで改めて掲載しておきます。

発表資料



 当日の発表資料です。

AWSのリージョンごとの料金の比較 2014/01/30版



※東京リージョンのみ消費税5%込みの料金なので、ご認識ください。
EC2の価格表 2014/01/30版

インスタンスタイプ vCPU ECU メモリ ストレージ 米国東部
(バージニア北部)
米国西部
(オレゴン)
米国西部
(北カリフォルニア)
欧州
(アイルランド)
アジアパシフィック
(シンガポール)
アジアパシフィック
(東京)
アジアパシフィック
(シドニー)
南米
(サンパウロ)
m3.medium 1 3 3.75 1 x 4 SSD 0.113 0.113 0.124 0.124 0.158 0.171 0.158 0.153
m3.large 2 6.5 7.5 1 x 32 SSD 0.225 0.225 0.248 0.248 0.315 0.342 0.315 0.306
m3.xlarge 4 13 15 2 x 40 SSD 0.450 0.450 0.495 0.495 0.630 0.684 0.630 0.612
m3.2xlarge 8 26 30 2 x 80 SSD 0.900 0.900 0.990 0.990 1.260 1.368 1.260 1.224
m1.small 1 1 1.7 1 x 160 0.060 0.060 0.065 0.065 0.080 0.088 0.080 0.080
m1.medium 1 2 3.75 1 x 410 0.120 0.120 0.130 0.130 0.160 0.175 0.160 0.160
m1.large 2 4 7.5 2 x 420 0.240 0.240 0.260 0.260 0.320 0.350 0.320 0.320
m1.xlarge 4 8 15 4 x 420 0.480 0.480 0.520 0.520 0.640 0.700 0.640 0.640
c3.large 2 7 3.75 2 x 16 SSD 0.150 0.150 0.171 0.171 0.189 0.192 0.189 -
c3.xlarge 4 14 7.5 2 x 40 SSD 0.300 0.300 0.342 0.342 0.378 0.383 0.378 -
c3.2xlarge 8 28 15 2 x 80 SSD 0.600 0.600 0.683 0.683 0.756 0.766 0.756 -
c3.4xlarge 16 55 30 2 x 160 SSD 1.200 1.200 1.366 1.366 1.512 1.532 1.512 -
c3.8xlarge 32 108 60 2 x 320 SSD 2.400 2.400 2.732 2.732 3.024 3.064 3.024 -
c1.medium 2 5 1.7 1 x 350 0.145 0.145 0.165 0.165 0.183 0.185 0.183 0.200
c1.xlarge 8 20 7 4 x 420 0.580 0.580 0.660 0.660 0.730 0.740 0.730 0.800
cc2.8xlarge 32 88 60.5 4 x 840 2.400 2.400 - 2.700 - 2.960 - -
g2.2xlarge 8 26 15 60 SSD 0.650 0.650 0.702 0.702 - - - -
cg1.4xlarge 16 33.5 22.5 2 x 840 2.100 - - 2.360 - - - -
m2.xlarge 2 6.5 17.1 1 x 420 0.410 0.410 0.460 0.460 0.495 0.505 0.495 0.540
m2.2xlarge 4 13 34.2 1 x 850 0.820 0.820 0.920 0.920 0.990 1.010 0.990 1.080
m2.4xlarge 8 26 68.4 2 x 840 1.640 1.640 1.840 1.840 1.980 2.020 1.980 2.160
cr1.8xlarge 32 88 244 2 x 120 SSD 3.500 3.500 - 3.750 - 4.310 - -
i2.xlarge 4 14 30.5 1 x 800 SSD 0.853 0.853 0.938 0.938 1.018 1.051 1.018 -
i2.2xlarge 8 27 61 2 x 800 SSD 1.705 1.705 1.876 1.876 2.035 2.101 2.035 -
i2.4xlarge 16 53 122 4 x 800 SSD 3.410 3.410 3.751 3.751 4.070 4.202 4.070 -
i2.8xlarge 32 104 244 8 x 800 SSD 6.820 6.820 7.502 7.502 8.140 8.404 8.140 -
hs1.8xlarge 16 35 117 24 x 2048 4.600 4.600 - 4.900 5.570 5.670 5.570 -
hi1.4xlarge 16 35 60.5 2 x 1024 SSD 3.100 3.100 - 3.100 - 3.440 - -
t1.micro 1 変数 0.615 EBS のみ 0.020 0.020 0.025 0.020 0.020 0.027 0.020 0.027


EC2の価格比較 2014/01/30版

インスタンスタイプ 米国東部
(バージニア北部)
米国西部
(オレゴン)
米国西部
(北カリフォルニア)
欧州
(アイルランド)
アジアパシフィック
(シンガポール)
アジアパシフィック
(東京)
アジアパシフィック
(シドニー)
南米
(サンパウロ)
m3.medium 100.00% 100.00% 109.73% 109.73% 139.82% 151.33% 139.82% 135.40%
m3.large 100.00% 100.00% 110.22% 110.22% 140.00% 152.00% 140.00% 136.00%
m3.xlarge 100.00% 100.00% 110.00% 110.00% 140.00% 152.00% 140.00% 136.00%
m3.2xlarge 100.00% 100.00% 110.00% 110.00% 140.00% 152.00% 140.00% 136.00%
m1.small 100.00% 100.00% 108.33% 108.33% 133.33% 146.67% 133.33% 133.33%
m1.medium 100.00% 100.00% 108.33% 108.33% 133.33% 145.83% 133.33% 133.33%
m1.large 100.00% 100.00% 108.33% 108.33% 133.33% 145.83% 133.33% 133.33%
m1.xlarge 100.00% 100.00% 108.33% 108.33% 133.33% 145.83% 133.33% 133.33%
c3.large 100.00% 100.00% 114.00% 114.00% 126.00% 128.00% 126.00% -
c3.xlarge 100.00% 100.00% 114.00% 114.00% 126.00% 127.67% 126.00% -
c3.2xlarge 100.00% 100.00% 113.83% 113.83% 126.00% 127.67% 126.00% -
c3.4xlarge 100.00% 100.00% 113.83% 113.83% 126.00% 127.67% 126.00% -
c3.8xlarge 100.00% 100.00% 113.83% 113.83% 126.00% 127.67% 126.00% -
c1.medium 100.00% 100.00% 113.79% 113.79% 126.21% 127.59% 126.21% 137.93%
c1.xlarge 100.00% 100.00% 113.79% 113.79% 125.86% 127.59% 125.86% 137.93%
cc2.8xlarge 100.00% 100.00% - 112.50% - 123.33% - -
g2.2xlarge 100.00% 100.00% 108.00% 108.00% - - - -
cg1.4xlarge 100.00% - - 112.38% - - - -
m2.xlarge 100.00% 100.00% 112.20% 112.20% 120.73% 123.17% 120.73% 131.71%
m2.2xlarge 100.00% 100.00% 112.20% 112.20% 120.73% 123.17% 120.73% 131.71%
m2.4xlarge 100.00% 100.00% 112.20% 112.20% 120.73% 123.17% 120.73% 131.71%
cr1.8xlarge 100.00% 100.00% - 107.14% - 123.14% - -
i2.xlarge 100.00% 100.00% 109.96% 109.96% 119.34% 123.21% 119.34% -
i2.2xlarge 100.00% 100.00% 110.03% 110.03% 119.35% 123.23% 119.35% -
i2.4xlarge 100.00% 100.00% 110.00% 110.00% 119.35% 123.23% 119.35% -
i2.8xlarge 100.00% 100.00% 110.00% 110.00% 119.35% 123.23% 119.35% -
hs1.8xlarge 100.00% 100.00% - 106.52% 121.09% 123.26% 121.09% -
hi1.4xlarge 100.00% 100.00% - 100.00% - 110.97% - -
t1.micro 100.00% 100.00% 125.00% 100.00% 100.00% 135.00% 100.00% 135.00%

レイテンシの比較



 レイテンシの比較です。これは、大阪の我が家から、各リージョンにt1.microのインスタンスを作って、Ping30回の平均の比較です。本来であればAZごとにやらないと余り意味はないのですが、参考までにです。また、東京リージョンにたてたインスタンスから各リージョンへの値も載せています。

From 米国東部
(バージニア北部)
米国西部
(オレゴン)
米国西部
(北カリフォルニア)
欧州
(アイルランド)
アジアパシフィック
(シンガポール)
アジアパシフィック
(東京)
アジアパシフィック
(シドニー)
南米
(サンパウロ)
大阪の我が家(ms) 191.272 139.592 126.323 400.590 98.989 21.014 135.342 498.746
東京リージョン(ms) 206.189 148.577 116.247 282.237 85.670 - 130.938 372.715


 レイテンシの比較については、軽く調べただけでも面白い発見が色々ありました。特にリージョン間の通信の安定性は、特筆物でした。これは、別途書こうと思います。

感想



 今回は、JAWSUG大阪初の平日開催です。私自身もなかなか休日に参加がするのが難しくなってきているので、仕事帰りに気軽に参加出来るというスタイルは気に入っています。少し時間の確保が難しくなっているのですが、可能な限り参加していこうと思います。


See Also:
JAWS-UG Osaka 第10回勉強会 | JAWS-UG
JAWS-UG Osaka 第10回勉強会のまとめ - Togetterまとめ
MINAMI ENGINE | 「JAWS-UG Osaka 第10回勉強会」に行ってきました。
life is funny: JAWS-UG Osaka 第10回勉強会に行ってきました
K Nishijimaのぶろぐ: JAWS-UG大阪 第10回勉強会に突撃してきました

角川文庫の70%オフセールで物色した本(1/28 9時59分まで)

 今話題のAmazonのKindleストアの角川書店の本の70%引きセールスをのぞいてみました。余りに多すぎたので、読む可能性がある角川文庫で値段でソートを掛けて検索してみています。


 角川文庫といえば、昔は書店で本の目録を配っていました。暇な時に家で眺めていてこれはどんな内容だろうと色々妄想していたこともあって、懐かしい本が一杯です。そこで、主に小・中・高校生の時に読みあさっていた本を中心に、読んだ本、読み漏れた本、色々ありますが、買おうかなと思った本をピックアップしてみました。


 私の読書歴の中での心残り(※)は、「ぼくらの」シリーズと「三毛猫ホームズ」シリーズを最後まで読み切ってないことです。これを機会に買おうかなと思いましたが、三毛猫ホームズの冊数の多さに気後れしています。ちなみにWikipediaさんを見ましたが、まだ三毛猫ホームズは完結していないのですね。恐るべし。※ちなみに中学校の時から田中芳樹が好きだったので、ほとんどのシリーズの完結を見たことがないです。
 歴史小説でいえば、池波正太郎海音寺潮五郎などは、読んだ本は全体の中のごく一部なので、この機会に買おうかなと思っています。あとは、司馬遼太郎の街道を往くをKindle化してくれませんかね。そのほかでは、Zガンダムとかも改めて読んでみたいなぁとか、10数年の時を経て新たに加筆修正したロードス島戦記も読んでみたい気がします。


2014/1/25追記:
リストがあまりに見づらかったので、再編成しました。

星新一のショートショートとエッセイ



 言わずと知れたショートショートの第一人者。残したショートショートは、1001本以上。1本あたりの分量が少ないので、Kindleにいれておいて隙間の時間に読むのが最適です。読み終わったら、Amazonさんが別の本を薦めてくれるので、無限ループにはまれること必要です。またショートショートの陰にかくれていますが、エッセイも秀逸です。子供の頃に星新一のエッセイを読んでいて、作家というのは面白い考え方をする生き物だなぁと思っていました。大人になって気が付きましたが、星新一が飛び抜けて独特な人だったようです。ちなみにエッセイは、「きまぐれ」で始まることが多いです。ただし、きまぐれロボットは、ショートショートで代表作です。

タイトル セールス価格
きまぐれロボット 102円
きまぐれエトセトラ 120円
きまぐれ学問所 144円
きまぐれ博物誌 126円
宇宙の声 114円
城のなかの人 144円
地球から来た男 144円
声の網 120円
おかしな先祖 126円
ごたごた気流 126円

歴史小説



 海音寺潮五郎の天と地とは、中学生の時に映画で見ました。圧倒的なスケールのものの、登場人物の心理や背景がよく解らなかったので、原作を読んでみたいと思っていました。そのまま忘れて、はや20年です。
 池波正太郎については、食事のエッセイなどはよく読んでたのですが、歴史小説はあまり読んでいないなぁと気が付きました。鬼平犯科帳や剣客商売など、長いシリーズを読むのはしんどいので、シリーズ物以外を読んでみようかと思いました。津本陽と宮城谷 昌光は、よく目にするけど読んだことがないです。これを機会に触れてみようかなと。

作者 タイトル セールス価格
海音寺潮五郎 天と地と(一) 120円
海音寺潮五郎 天と地と(二) 120円
海音寺潮五郎 天と地と(三) 120円
海音寺潮五郎 天と地と(四) 120円
海音寺潮五郎 天と地と(五) 120円
池波 正太郎 西郷隆盛 138円
池波 正太郎 戦国と幕末 162円
池波 正太郎 英雄にっぽん 186円
池波 正太郎 賊将 198円
津本陽 信長の傭兵 138円
宮城谷 昌光 管仲(上) 150円
宮城谷 昌光 管仲(下) 150円

阿刀田高の古典シリーズ



 星新一と同じく阿刀田高もショートショートの名手と名高いです。それ以外にも古典を解りやすく紹介した本が秀逸です。角川文庫ではないですが、「ギリシア神話を知っていますか」で始まり数々の著書があります。中学くらいの時に読んで、教養がある人というのはこんな人なんだなぁと憧れました。憧れるだけで、原本を読むとかはしませんでしたが。
 角川文庫からも何冊か出しているようです。ダンテの神曲は、当時のイタリアの政争を反映しているなど、目からウロコでした。後はまだ読んでないのですが、日本語を書く作法・読む作法は購入しました。私の中で、解りやすく説明するという点で、阿刀田さんは最上位です。その文章作法にふれてみたいと思います。

タイトル セールス価格
エロスに古文はよく似合う 150円
楽しい古事記 162円
やさしいダンテ<神曲> 174円
日本語を書く作法・読む作法 150円

小説いろいろ



 「スローカーブを、もう一球」は、一度読もうと思いつつ何故か読んでいなかった本です。江夏の21球を始め、スポーツの名場面を丹念に取材・描写としたルポとして評価が高いです。早速読みましたが、中々ジーンときます。時代の違いを感じますが。。。また万城目学や伊坂幸太郎もKindleで読めるようになっているのですね。この値段だったらKindle版を買って、本棚に眠っているのを捨ててても良いかなと思います。

作者 タイトル セールス価格
山際 淳司 スローカーブを、もう一球 162円
宗田 理 ぼくらの七日間戦争 162円
万城目 学 鴨川ホルモー 150円
万城目 学 ホルモー六景 162円
伊坂 幸太郎 グラスホッパー 174円

赤川次郎の三毛猫ホームズ



 初期の暗い雰囲気だったのが、一転安心して読めるライトな感じになっています。最後はどうなっているのか気になってリストアップしたけど、冊数をみて断念しました。買うだけかって、暇な時に読むのも1つですかね。ちなみに、まだ完結していないと知って、さらにびっくりしました。あと、興味をひいたのが、「ぼくのミステリ作法」。脅威の多作作家の秘密が面白そうです。

タイトル セールス価格
ぼくのミステリ作法 126円
三毛猫ホームズの推理 162円
三毛猫ホームズの傾向と対策 162円
三毛猫ホームズの怪談 162円
三毛猫ホームズの駈落ち 168円
三毛猫ホームズの恐怖館 174円
三毛猫ホームズの騎士道 174円
三毛猫ホームズの大改装 132円
三毛猫ホームズの無人島 138円
三毛猫ホームズのプリマドンナ 138円
三毛猫ホームズの四捨五入 138円
三毛猫ホームズの好敵手 138円
三毛猫ホームズの映画館 138円
三毛猫ホームズの最後の審判 138円
三毛猫ホームズの世紀末 138円
三毛猫ホームズの〈卒業〉 144円
三毛猫ホームズのクリスマス 144円
三毛猫ホームズの感傷旅行 144円
三毛猫ホームズの四季 144円
三毛猫ホームズの家出 150円
三毛猫ホームズの騒霊騒動 150円
三毛猫ホームズのフーガ 150円
三毛猫ホームズの登山列車 150円
三毛猫ホームズの歌劇場 150円
三毛猫ホームズの幽霊クラブ 150円
三毛猫ホームズの暗闇 150円
三毛猫ホームズの心中海岸 150円
三毛猫ホームズの暗闇 150円
三毛猫ホームズの失楽園 150円
三毛猫ホームズと愛の花束 150円
三毛猫ホームズの正誤表 150円
三毛猫ホームズの恋占い 150円
三毛猫ホームズのびっくり箱 150円
三毛猫ホームズの安息日 150円
三毛猫ホームズの黄昏ホテル 162円
三毛猫ホームズの狂死曲 162円
三毛猫ホームズの追跡 162円
三毛猫ホームズの運動会 186円
三毛猫ホームズの犯罪学講座 186円

まとめ



 50冊くらいポチっても1万円未満というこの安さ。読む時間が全く無いですが、とりあえず気になる本は買っておこうかと思います。あとこう手のキャンペーンで成功して、最終的にはKindle書籍の低価格化が進んでくれることを願いします。販売当初は紙版と同じくらいの値段でも問題ないのですが、発売後何十年もたったようなものは安くしたほうが、トータルの売上があがるのではと思います。


See Also:
今まで読んで良かった本 100冊