2011-09-15

Elastic Beanstalk本を読んだ

admin AWS

8月にO'ReillyからAWS Elastic Beanstalkの解説本（英語）が出版されていたので読んでみました。まだまだ誰もが知る製品とはいえないBeanstalkですが、すでに紙の本が出版されて本屋に並んでいるあたりに、米国においてAWSが完全な市民権を得ている雰囲気を感じます。

Elastic Beanstalkは、ごくごく簡単に言えば、アプリケーションをAWSの様々なリソース上に素早くdeployするためのプロダクトです。現在はコンテナとして用意されているのはTomcatのみですが、今後はJava以外の言語も含めて、複数の環境がサポートされていくようです。詳しくは、AWS公式ブログの記事が参考になると思います：

Elastic Beanstalk - O'Reilly

Elastic Beanstalk: Simple Cloud Scaling for Java Developers

作者: Jurg van Vliet,Flavia Paganelli,Steven van Wel,Dara Dowd
出版社/メーカー: O'Reilly Media
発売日: 2011/08/06
メディア: ペーパーバック
クリック: 1回
この商品を含むブログ (1件) を見る

著者はProgramming Amazon EC2: Survive your Successと同じJurg van Vliet氏と Flavia Paganelli氏を含めた4名の方で、AWS Solution Providerの9apps（オランダ）のエンジニアの皆さんです。

この本は50ページしかないのですが、Elastic Beanstalkの解説に加えて、実際にURL短縮ツールをBeanstalkを使ってAWS上にdeployする例が紹介されてます。Beanstalkでは、Auto Scalingによって自動的にEC2インスタンスが起動・停止されるので、ローカルにデータを保存するというアプローチは取れないわけですが、そのためにどのようなアーキテクチャをとるべきかといった点も簡単に説明されています。Hudsonを使ってCIの環境を構築している点など、実務的な視点が貫かれているのが特徴だと感じました。

AWS tips

AWSのwebサイトなどに明示的に書かれていない内容で、執筆陣が経験的に学んだAWS利用上のtip（コツ）的な内容も有意義だと感じました。アベイラビリティ・ゾーンを複数利用することが可用性向上に極めて重要であり、EC2障害時に有効に機能する方策であることなどもしっかり書かれています（p.19）。

Beanstalk固有の話題ばかりではないですが、3箇所ほど印象的な部分を引用すると・・・

There is an EBS volume and ephemeral storage. Both are unreliable for storage that needs to be persisted. (p.4)
参考訳：EBSとephemeral storageがあるが、どちらもストレージとして十分な信頼性があるわけではないので（S3にスナップショットをとったり、DBに記録するなどの方法で）永続化する必要がある。

EBSのスナップショットはS3に保存されるので、スナップショットまでとっておけば、相当安心できますねー。

Elastic Beanstalk is not a PaaS. You can forget about servers for a while, but if you are not happy with them, you can take control. (p.17)
参考訳：BeanstalkはPaaSではない。しばらくは個別のサーバーについて考えなくて済むが、もし都合が悪いことがあれば細かく制御することができる。

AWS公式ブログにも書かれていますが、必要に応じてサーバー単位でトラブルシュートを行ったり、ロードバランサーの設定を変更したりといったことが可能であったり、Elastic Beanstalkは、いわゆるPaaSとは毛色の違うサービスなのですが、案外メッセージが伝え切れていないのかな、と思うこともあります。

It is important to realize that the command-line tools always implement 100% of the available features. The Console does not. (p.20)
参考訳：コマンドラインツールは100%の機能を常に網羅している一方で、マネージメント・コンソールは必ずしもそうではない。

スクリプトで自動化したりする上で、実際にはコマンドラインツールが有用な局面も多いのですが、一部の操作についてはコマンドラインツールを使わないと行けないという現実があります。GUIで100%の機能が網羅されているとさらに良いですね。

Hacking Elastic Beanstalk

本書の第4章は"Hacking Elastic Beanstalk"と題されていて、Beanstalkの応用的な話題として、Apache httpdをNginxに置き換えたり、OpenJDKをSun JDKに置き換えたりといった内容が触れられてます。

まとめ

ページ数の割に少々値段が張りますが、Beanstalkの解説として記念碑的な本ですし、EC2などについても学べる内容が大ですので、Beanstalkに興味があれば読んでみて損はないと感じました。

この記事のリンクはAmazon.co.jpのアフィリエイトになってますが、Amazon.com（米国）だと$9.99でKindle版を購入できます。円高のおかげで、今なら800円未満です。また、O'Reillyのオンラインサイトからは、$16.99ですが、DRMフリーなePub, Mobi, PDFの電子ファイル形式で購入することも可能です。

2011-09-07

EC2インスタンスを自動構成する(1/2)

admin AWS Cloud Computing

「クラウド・コンピューティング」採用の正否は、様々な管理・保守作業の自動化の巧拙によって決まるような気がしています。せっかくクラウドを使っても、今までと同じように人手をかけていてはクラウドのメリットを十分に活かせているとは言いがたいでしょう。典型的には、クラウド・ベンダーの用意したAPIを通じてリソースの制御を行うアプローチがありますが、自動化に使えるのはAPIだけではありません。

ここでは、AWS標準で追加料金なしに利用できるCloudInitとAWS CloudFormationの2つを使って、EC2の構成作業の一部を自動化する方法を考えてみます。
CloudInitでは、User Dataとして渡した情報などを元にEC2インスタンス起動時に様々な作業を自動的に行わせることができます。AWS CloudFormationでは、JSONで記述した内容に従って、単体のEC2インスタンスに留まらず、AWS各サービスの様々なリソースをアトミックに統御することができます。また、リソース作成時に動的に変更したい内容についてはパラメータとしてJSONから括りだしておき、実行時にGUIから簡単に指定したりといったことも可能です。

単純な例として、SSHやtelnetでインスタンスにログインすることなく、フォワーディング・プロキシ・サーバーを構成してみたいと思います。

プロキシ構成の手順

ここで、プロキシ・サーバーのソフトウェアとしては標準的なSquidを利用しますが、とりあえずであっても実際に使えるようになるまで以下のような手順が必要となります。

YUMレポジトリーからSquidをインストール
squid.confの編集
1. 自分のIPアドレスを、Squidへのアクセスを許可するIPアドレスとして設定
2. Squidがlistenするポート番号を設定
再起動時に自動でSquidデーモンが立ち上がるように設定

Squidのインストールだけであれば、あらかじめインストール済みのAMIを作成したり、起動時に最新版のインストールを実行するスクリプトを組み込んだAMIを作成すると言った代替手段がありますが、その場その場で異なるIPアドレスを動的に設定するのは面倒です。

CloudInitによってこれらの構成を一括して自動的に実行してみます。

CloudInitによるEC2インスタンスの自動構成

CloudInitはUbuntu由来のソフトウェアですが、EC2上の標準Linux環境であるAmazon Linuxでも利用できます。CLoudInitで自動実行できる項目と設定例は、CloudInitのソースツリーに含まれていますが、securityに関するアップデートを初回起動時に自動適用すると言ったことも可能です。（Amazon Linuxの場合はデフォルトの動作です。）

CloudInitではUserDataにシェルスクリプトを指定して任意の操作を実行することもできるのですが、パッケージの追加といった典型的な作業であれば

yum install foo -y

といったコマンドを書き連ねることなく、所定の書式にしたがって簡単に指定できます。今回は、Squidの構成のために、yumパッケージのインストールと、squid.confの編集のためのコマンド実行の双方の機能を利用します。

パッケージのインストール（packages）

非常に単純ですが、以下のようにしてcloud-configにパッケージを指定すると自動的にインストールされます。ディストリのパッケージング・システム（Amazon Linuxの場合はYum）を利用しているので、その時点での最新バージョンがレポジトリーから取得され、依存関係も面倒を見てもらえます。

#cloud-config
packages:
- squid

コマンドの実行（runcmd）

コマンドを実行するためには、先ほどのpackagesと同様にcloud-configにruncmdに続けてコマンドを記述します。Squidの設定ファイルであるsquid.confのうち、アクセスを許可するネットワークを指定するacl localnet src行と、Squidがlistenするポート番号を指定するhttp_portを編集します。行の指定方法にエレガントさを欠きますが、sedによってソースIPアドレスを挿入し、ポート番号を書き換えます。また、デーモンの起動と、インスタンスを再起動した場合も自動的にSquidが起動するための設定も行います。

runcmd:
- [sed, -i, "/RFC 4291/a acl localnet src AAA.BBB.CCC.DDD/32", /etc/squid/squid.conf]
- [sed, -i, "/^http_port/c http_port 8080", /etc/squid/squid.conf]
- [chkconfig, squid, "on"]
- [service, squid, start]

リストとして渡すために、カンマで区切るのがポイントです。

User Dataは16384バイトに制限されているため、指定できる内容にも制限が生じますが、内容をgzipで圧縮したり外部のURLから読み込むといった手段にも対応しています。

EC2インスタンスの起動時にUser Dataを指定する方法

GUIであるManagement Consoleを利用する場合、EC2を起動する際のウィザード内で以下のようにUser Dataを直接指定できます。（ファイルからアップロードすることも可能です。）
Management ConsoleからUser Dataを指定する

packagesとruncmdはつなげて書けるので、User Data全体としては以下の内容をウィザードに貼り付けることになります。

#cloud-config
packages:
- squid

runcmd:
- [sed, -i, "/RFC 4291/a acl localnet src AAA.BBB.CCC.DDD/32", /etc/squid/squid.conf]
- [sed, -i, "/^http_port/c http_port 8080", /etc/squid/squid.conf]
- [chkconfig, squid, "on"]
- [service, squid, start]

CLI（EC2 API tool）のec2-run-instancesコマンドの"-d"や"-f"オプションでもUser Dataを指定することができます。コマンドについて詳しくはCLI Reference。

Squid（CloudInit）の動作確認

以上のようにUser Dataを指定して起動したEC2インスタンスのPublic DNSないしグローバルIPアドレスをプロキシ・サーバーとして指定してください。ブラウザでcheckip.amazonaws.comにアクセスするとHTTPリクエストのソースIPアドレスが表示されますが、自分の端末のアドレスの代わりにEC2インスタンスのグローバルIPが表示されていればプロキシ経由でアクセスできていることが確認できます。

期待通りに動作しない場合、CloudInitの動作をチェックするためには以下のログが参考になります。

/var/log/messages

Sep  7 14:48:38 ip-nnn-nnn-nnn-nnn [CLOUDINIT] 2011-09-07 14:48:38,638 - cloud-init-cfg[INFO]: cloud-init-cfg ['package-setup']
Sep  7 14:48:53 ip-nnn-nnn-nnn-nnn yum: Installed: libtool-ltdl-2.2.10-1.8.amzn1.i686
Sep  7 14:48:53 ip-nnn-nnn-nnn-nnn yum: Installed: perl-DBI-1.609-4.4.amzn1.i686
Sep  7 14:48:54 ip-nnn-nnn-nnn-nnn yum: Installed: 7:squid-3.1.10-1.7.amzn1.i686
Sep  7 14:48:54 ip-nnn-nnn-nnn-nnn [CLOUDINIT] 2011-09-07 14:48:54,923 - cloud-init-cfg[INFO]: cloud-init-cfg ['runcmd']
（中略）
Sep  7 14:48:55 ip-nnn-nnn-nnn-nnn [CLOUDINIT] 2011-09-07 14:48:55,688 - cloud-init-run-module[INFO]: cloud-init-run-module ['once-per-instance', 'user-scripts', 'execute', 'run-parts', '/var/lib/cloud/data/scripts']
Sep  7 14:48:56 ip-nnn-nnn-nnn-nnn squid[949]: Squid Parent: child process 952 started

最後でSquidデーモンがが無事に起動しています。

/var/log/cloud-iinit.log

（略）
Dependencies Resolved

================================================================================
 Package           Arch      Version                    Repository         Size
================================================================================
Installing:
 squid             i686      7:3.1.10-1.7.amzn1         amzn-updates      1.9 M
Installing for dependencies:
 libtool-ltdl      i686      2.2.10-1.8.amzn1           amzn-main          31 k
（中略）
Starting squid: .[  OK  ]

こちらは標準出力の結果です。その他の処理が行われた後、YumによるSquidパッケージのインストールと、デーモンの起動が行われている様子が分かります。

まとめ

ここまでで、CloudInitを使うことで一切サーバーにログインすることなくSquidによるプロキシ・サーバーを構築することができました。ただ、自分のネットワークアドレスなどを元にUser Dataをイチイチ編集して指定し直す作業は不便です。また、Security Groupの設定などでは、Squidの構成に使ったソースIPやポート番号と行ったパラメーターを改めて指定する必要があり、いかにも二度手間です。

冒頭で書いたように、次回はAWS CloudFormationというサービスを使って、自分のネットワーク・アドレスとポート番号を、GUIであるManagement Consoleから指定できるパラメータとして括りだして、User Dataを直接編集せずにproxyを起動できるようにします。また、EC2インスタンス上の設定だけではなく、Security Groupの構成もCloudFormationによって自動化します。

2011-08-27

ルーターからクラウドを操る

admin AWS net

いかにも釣りっぽいタイトルで申し訳ないとしか言いようがないのですが、YAMAHA RTXシリーズからAWSのAPIを叩く実験をしてみたので、そのメモです。

YAMAHA ルーターのLua スクリプティング機能

最近のYAMAHAのファームにはLua スクリプティング機能が付いていて、定期的にconfigをダウンロードして適用させたり、時間帯に応じてルーティングを変えたりといった柔軟な運用ができます。詳しくは本家のサイトに解説されています。この機能を使ってAWSのAPIを叩けたらいろいろなことができるんじゃないかと思って、POC的に実験してみました。

YAMAHAファームが準拠しているのはLua 5.1.4ということになっていますが、フル仕様ではなくサブセットのみが実装されているので、やや工夫が必要でしたが、とりあえずDescribeSecurityGroupsでセキュリティ・グループのリストを取得するスクリプトを書いてみました。

AWS REST APIのシグネチャ計算

HMAC-SHA1の計算とBASE64 エンコーディングが必要になるので、以下の2カ所から先達のスクリプトを探してきました。
SHA-1 and HMAC-SHA1 Routines in Pure Lua (by Jeffrey Friedl. Public Domain)
Base Sixty Four (by Alex Kloss. LGPL2)

AWSのドキュメント（Making Query Requests）に従ってクエリを組み立てて、シグネチャを計算します。

access_key = "YOUR_ACCESS_KEY_ID"
secret_key  = "YOUR_SECRET_ACCESS_KEY"
api             = "DescribeSecurityGroups"

api_version   = "2011-07-15"
host              = "ec2.amazonaws.com"
http_method = "GET"

--ISO8601でタイムスタンプを取得
time_stamp_raw = os.date("!%Y-%m-%dT%H:%M:%S.000Z")
time_stamp        = string.gsub(time_stamp_raw, ":", "%%3A")

--アクセスキー以外の引数を昇順に並べたクエリを組み立てる
s2s = http_method .. "\n" .. host .. "\n/\nAWSAccessKeyId=" .. access_key .. "&Action=" .. api .. "&SignatureMethod=HmacSHA1&SignatureVersion=2&Timestamp=" .. time_stamp .. "&Version=" .. api_version

--HMAC-SHA1の計算結果をBASE64エンコーディングしてシグネチャを生成
signature = base64(hex_to_binary(hmac_sha1(secret_key, s2s)))

なお、オリジナルのHMAC-SHA1の計算ロジックをYAMAHA版Luaの制約に合わせて修正する必要がありました。引っかかった制約は、

数値が整数のみで浮動小数点数が扱えない
Mathライブラリのmodf関数が実装されていない

の2点でした。

今回はクエリの文字数が一定であれば計算結果が変わらない部分だったので、計算リソースの節約の意味も兼ねて、結果をハードコーディングすることで回避しました。その他のAPIも同じスクリプトで扱うようにする場合は、APIコールと計算結果をtableで関連づけるような実装になるかと思われます。（Luaにおけるtableは、RubyのHashのようなものです。）

--浮動小数点数とmath.modfはYAMAHA Luaで実装されていない
--local B1, R1 = math.modf(msg_len_in_bits  / 0x01000000)
--local B2, R2 = math.modf( 0x01000000 * R1 / 0x00010000)
--local B3, R3 = math.modf( 0x00010000 * R2 / 0x00000100)
--local B4       = 0x00000100 * R3

--EC2 DescribeSecurityGroupsコールのためのdirty hack
if msg_len_in_bits == 2040 then
    B1, B2, B3, B4 = 0, 0, 7, 248
elseif msg_len_in_bits == 672 then
    B1, B2, B3, B4 = 0, 0, 2, 160
end

ちなみに、浮動小数点数さえ使えれば、math.modfを実装するのは簡単で、以下のようになるはずです。

--math.modf
function modf_(n)
    if n > 0 then
        f = n % 1
    else
        f = n % -1
    end
    i = n - f
    return i, f
end

HTTPリクエストの発行と結果の取得

YAMAHA ルーターのLuaでは、configの操作など、標準Lua以外のライブラリが実装されています。そのうちの一つであるrt.httprequestを使ってEC2エンドポイントにAPIコールを投げます。rt.httprequestでは結果のボディをファイルに書き込むことができるので、以下の例ではルーターの内蔵メモリに書き込んでいます。そのほか、機種によって差がありますが、ルーターに挿入したmicroSDやUSB接続されたストレージにファイルを書き込むことができます。

--シグネチャをつかってクエリを組み立てる
query = "Action=" .. api .. "&AWSAccessKeyId=" .. access_key .. "&Version=" .. api_version ..  "&Timestamp=" .. time_stamp_raw .. "&Signature=" .. signature .. "&SignatureVersion=2&SignatureMethod=HmacSHA1"

--rt.httprequestではSSLは未実装
req_url = "http://" .. host .. "/?" .. query

--リクエスト・パラーメータを格納したテーブルを作成してGETを発行
--rsp_t.codeでHTTPステータスコード、rsp_t.errでエラーメッセージを確認可能
file_path = "/sg_out.txt"
req_t      = {url=req_url, method="GET", save_file=file_path}
rsp_t      = rt.httprequest(req_t)

実行結果の確認

tftpでスクリプトをルーターにアップロード
ルーターでスクリプトを実行
結果のファイルをローカルにダウンロードして確認

という手順で動作確認を行います。

Macですが以下のようにtftpでファイルをアップロードしました。直後にgetを行うため、個人的にはインタラクティブ・モード（？）が使いやすいと感じました。ROUTER_IP_ADDRESSとROUTER_ADMIN_PASSORDの部分は、それぞれ適切な値に置き換えてください。

$ tftp 
tftp> connect ROUTER_IP_ADDRESS
tftp> put desc_sg.lua /desc_sg.lua/ROUTER_ADMIN_PASSWORD
Sent 34235 bytes in 0.6 seconds

ルーターでLua スクリプトを実行します。administratorで実行している点に注意。

# lua desc_sg.lua

結果をローカルPCにダウンロードして内容を確認します。

$ tftp 
tftp> connect ROUTER_IP_ADDRESS
tftp> get /sg_out.txt/ROUTER_ADMIN_PASSWORD sg_out.txt
Received 2130 bytes in 0.1 seconds
tftp> quit
$ cat sg_out.txt
846
<?xml version="1.0" encoding="UTF-8"?>
<DescribeSecurityGroupsResponse xmlns="http://ec2.amazonaws.com/doc/2011-07-15/">
    <requestId>########-####-####-####-############</requestId>
    <securityGroupInfo>
        <item>
            <ownerId>
  （以下省略）

制約とハマリどころ

繰り返しになる内容も多いですが、YAMAHA Lua上でAWS APIを叩く上で制約となりそうな点を列挙します。MacやLinux用のものとは言語仕様やライブラリの実装状況に差があるので、こまめに実機でテストするのが無難だと感じました。自分はRuby (Sinatra) でスタブを書いて、デバッグを行いました。

浮動小数点が使えない
一部関数が実装されていない
URL末尾に'/'（スラッシュ）がないとinvalid URLとなってリクエストが飛ばない
URLが255文字までに制限されている。そのため、GETで叩けるAPIコールは制限が厳しい。
rt.httprequestは勝手にURLエンコーディングしてくれるので、"="を"%3D"に置き換えておくと、さらに"%"をエスケープして"%253D"に変換されてしまうのでシグネチャが一致しないことになる。
ボディの大きさにも制限がある。
SSLが使えないので、Access Key IDやクエリのパラーメーターが平文で飛んでしまう。

まとめ

YAMAHA ルーター上のLua スクリプティング機能を使ってEC2 APIの1つであるDescribeSecurityGroupを発行することができました。色々と制約はありますが、スクリプトからVPCの作成とconfigまでできたりしてしまうとおもしろいかもしれないと感じました。

なお、Credentials （Access Key IDなど）の扱いには注意する必要があるかと思われます。rt.httprequestの制限によってSSLが使えないこともありますが、実際にはIAMを使って権限に制約をつけた鍵を利用するのがいいかと思われます。

（言わずもがなですが、私の勤め先などは本記事の内容に一切関知していません。）

gistに貼っておきました → https://gist.github.com/1174442

2011-05-27

ELBのIPv6対応について

AWS

Amazon クラウド（Amazon Web Services）で提供されているロードバランサーElastic Load BalancingがIPv6対応しました。

当座はUS EastとEU Westリージョンのみですが、Tokyoリージョンなどにも順次展開されていくものと思われます。新しく作成されたELBだけでなく、既存のELBについても自動的にv6対応が行われ、US EastかEU WestのELBを表示させると、以下のスクリーンショットのようになっています。

今まで一つのDNS名しかアサインされていなかったのですが、"ipv6"と"dualstack"というprefixのついた新しい名前が追加されています。

my-load-balancer-XXXXXXXXX.[eu-west-1|us-east-1].elb.amazonaws.com
ipv6.my-load-balancer-XXXXXXXXX.[eu-west-1|us-east-1].elb.amazonaws.com
dualstack.my-load-balancer-XXXXXXXXX.[eu-west-1|us-east-1].elb.amazonaws.com

元々持っていたDNS名はAレコードのみ、"ipv6"はAAAAのみ、"dualstack"はAとAAAAを返します。

% host my-load-balancer-241488968.eu-west-1.elb.amazonaws.com
my-load-balancer-241488968.eu-west-1.elb.amazonaws.com has address 46.137.83.224

% host ipv6.my-load-balancer-241488968.eu-west-1.elb.amazonaws.com
ipv6.my-load-balancer-241488968.eu-west-1.elb.amazonaws.com has IPv6 address 2a01:578:3::2e89:53e0

% host dualstack.my-load-balancer-241488968.eu-west-1.elb.amazonaws.com
dualstack.my-load-balancer-241488968.eu-west-1.elb.amazonaws.com has address 46.137.83.224
dualstack.my-load-balancer-241488968.eu-west-1.elb.amazonaws.com has IPv6 address 2a01:578:3::2e89:53e0

ここで、以前のまま、元々の名前をCNAMEで使っているような場合は特に問題ないものの、新しくELBを設定する場合に「どうせならv6対応しておこう」と考えて"dualstack"を設定すると、国内の一部クライアント環境で接続性やパフォーマンス上の問題が生じる可能性があります。

NTTのフレッツではフレッツスクエアやひかりTVでIPv6を使用していますが、v6でフレッツ網の外部と通信ができない場合でもv6のアドレスがアサインされるため、DNSがAAAAレコードを返すホストとフレッツを利用しているクライアントとの通信時に、まずv6で通信を試みて、一度失敗してv4で再度通信を試みるという動作が行われるため、v6対応のホストではwebページの閲覧の際などに遅延が生じる可能性があります。この問題については、NTT公式ページに説明がありますし、このページに詳しい解説があります。

Amazon固有の課題ではなく、また、幸いなことにELBにはIPv4アドレスのみに対応したDNS名も用意されており、いわばOpt-in形式となっています。ただちに何らかの対応が必要になる性質の問題ではありませんが、若干の注意が必要になるかと思われますので、自分のメモがてらblogに書いておきます。

IPv6 Dayに向けた注意喚起に関するリンクを追加（6/2）
フレッツ光ユーザーは6月8日の「IPv6 Day」に注意、Webが見られぬ恐れ | 日経 xTECH（クロステック）
http://recommend.yahoo.co.jp/ipv6day/index.html（Yahoo! JAPAN）
http://www.microsoft.com/japan/mscorp/mic/interop/ipv6ie.aspx（日本マイクロソフト）

2011-04-23

「クラウド入門」の話をしました

Cloud Computing

21日、アマゾン主催の「エンジニアのためのクラウド勉強会」にて「クラウド入門」というタイトルで話をさせていただきました。（資料や講演内容はアマゾンの正式なレビューを経たものではなく、あくまで私個人の見解を述べたものです。）

2011-04-21 クラウド勉強会

View more presentations from Koichiro Doi.

当初、入門編 + 技術寄りの話題×2本の三本立て構成の予定だったのですが、リモートから講演する予定だったダブリンのエンジニアが急きょ登壇できなくなり、濃い話を期待して下さっていた来場者の方には少し物足りなかったかもしれませんが、私なりの「クラウド」の解釈と、AWSの紹介について1時間強説明させていただきました。

オリジナルの考え方ではありませんが、私はクラウド・コンピューティングの本質は技術論ではないと思っています。クラウド=仮想化インフラとか、これこれの要素技術を組み合わせたものがクラウドであるといったような、要素技術から出発するクラウド論には違和感を感じています。だから、IaaS, PaaS, SaaSというような括りでクラウド・ベンダーを分類するような試みも、あまり意味がないのではないかと思います。こういった考え方は、特に調達などに関わる機会のあるインフラ系エンジニアの方は直感的に理解されている方が多いと思うのですが、来場者の方がクラウドについて考える上で何かのヒントになったのであれば幸いです。

セミナー後に懇親会があったのですが、すでにAWSを使っていただいている方も多数参加いただいていて、かなり突っ込んだ話もさせていただけて楽しかったです。

平日の遅い時間にも関わらず、多くの皆様にお集まりいただきまして誠にありがとうございました。

ちなみに、会場でご質問をいただいた「AWSを使ったディザスタ・リカバリ」については、AWSエバンジェリストである玉川氏の講演資料が参考になるかと思われます。

また、既存オンプレ環境の延長として、文字通り仮想プライベート・クラウド（Virtual Private Cloud）を実現できるVPCについては、玉川氏のブログと製品ページのリンクを紹介させていただきます：
Amazon Web Services ブログ: 【AWS発表】 Amazon EC2の新しい仮想ネットワーキングを発表
 Amazon Virtual Private Cloud (VPC)（英語）

最後に私の話で触れた2冊の書籍のリンクも貼っておきます。ぜひ「アマゾンで」お買い上げください。（注意：リンクはアフィです。）

ITにお金を使うのは、もうおやめなさいハーバード・ビジネススクール・プレス (Harvard business school press)

作者: ニコラス・G・カー,清川幸美
出版社/メーカー: ランダムハウス講談社
発売日: 2005/04/07
メディア: 単行本
購入: 5人クリック: 63回
この商品を含むブログ (38件) を見る

クラウド化する世界~ビジネスモデル構築の大転換

作者: ニコラス・G・カー,村上彩
出版社/メーカー: 翔泳社
発売日: 2008/10/10
メディア: 単行本
購入: 21人クリック: 162回
この商品を含むブログ (159件) を見る

追記（04/23 23:38）
id:iRSSさんがメモをまとめてくださいました。

2011-02-20

粛正の朝

admin life

Gmailのメールボックスに飛び込んでくるアラート系/ニュース系のメーリングリストのうち、着信時点ですでにTwitterやRSSリーダー経由で情報が手に入っていたり、興味がなかったりして、読まずに捨てているものが多いことに気がついたので整理してみました。inboxが溢れているのは精神的にも作業効率的にもよろしくないので、20分ほどの作業の対価として得られたものは大きかったと思います。

同時に大量に購読停止を行うと、同じことを実現するためにも様々な方法があることが分かって勉強になりました。メモがてら簡単に整理してみます。

一発停止

メール文中のリンクに、こちらのアカウントやアカウントを表す文字列が含まれていて、そのURLを叩くだけで解除が終わる。簡単至極で最速の方法ながら、「解約が終了しました」というメッセージしか表示されない場合が多いので、誤ってクリックしてしまった際に再度登録する手間が面倒ではないかと思う。その点、Herokuのnews letterは気が利いていて、「お客様のメールへの送信を解除しましたが、取り消す場合はここをクリックして下さい」というようなメッセージが表示された。

一発停止 + 確認

上と同様にリンクにアカウント情報が含まれているものの、クリックすると「"foo@example.com"の購読を停止しますがよろしいですか。」という確認が出て、「確認」や「送信」というボタンを押すと購読停止が成立するもの。一手間多いようだが、誤ってクリックしてしまった場合でも操作を取り消すことができるので穏当だと思われる。

購読停止ページへのリンクのみ

アクセスすると、ブランクのテキストボックスがあって、そこに自分のメールアドレスを入れてフォームを送信すると購読停止ができるタイプ。少し困ったのが、学生時代に購読したものなどは受信アドレスが大学のものだったりして、当たり前ながらGmailアドレスを入力するとエラーが出てしまった点。一度メールボックスに戻って、何のアドレスで受信しているかを確認する必要があるのが億劫に感じた。ただ、業者側からすると、不必要な顧客情報をメール本文に盛り込まないようにするという配慮なのかもしれない。メールを転送した場合でも、このパターンなら最初の受信者を隠蔽できる。

ログインしてからメール受信設定をするもの

オンラインショッピングの会員などとしてメールを受信している場合は、ログインを求められることが多い。その中でも、メールの文中に、直接メーリングリストの管理画面へのリンクを提供してくれているメールと、「購読を停止するためにはログイン後に"個人設定"から設定して下さい」とだけしか書いていない不親切なものがあった。

特定のアドレスにメールで申請する

もっとも購読停止の敷居が高かったのは、メール文中に書いてあるメールアドレスに対して「受信停止を希望する旨」を記入して連絡せよ、というタイプ。担当者の方も気の毒な感じがする。刺身タンポポの比ではない。今回整理したメーリングリストの中で「PFU ScanSnapニュース」だけが本方法を取っていた。

（管理システムにメールを送る）

本文に"unsubscribe"などと書いて管理用アドレスに送信すると自動的に購読が解除されるタイプ。昔はOSS系のメーリングリストで多かったような気がするものの、今回は一つもなかった。

あと、購読停止について確認が来る場合と来ない場合も業者によって分かれていて興味深かったです。

2011-01-10

■

芥川龍之介の人生が一行のボオドレエルにも若かないかどうかは分からないが、我が輩の人生は一文字の芥川龍之介にも若かない。