Asgardを使ってみる。
Asgardって？
AsgardはNetflixが出しているオープンソースのAWSマネージメントコンソールです。特にAWSだけでなくても使えるようにしてあるようにもみえますが、実質上はAWSのみが現在対応されています。あまり日本で使っている人をみかけないのですが、実は結構使えるだろうなとあてをつけていて、今回AWS温泉ハッカソンがあるのでせっかくなのでまずはAsgardをいじってみることにしました。
AsgardのWebサイトはこちら。
Asgardの特徴
AsgardがAWSのマネージメントコンソールと違って最も特徴的な点は、AWSのマネージメントコンソールが各サービス毎の管理機能を提供しているのに対して、Asgardはアプリケーションから見た管理にかなり重点をおいています。Appとよばれるアプリケーションのグループを作って、そこに各サービスを割り当てていくような方法を取ります。
Asgardをインストールしてみよう
https://github.com/Netflix/asgard/wiki
のとおりにやるだけですが、まずは下記のものが必要になります。
Asgardをインストールするサーバで、
java -Xmx1024M -XX:MaxPermSize=128m -jar asgard-standalone.jar
とすれば良いだけです。インストールはこれだけ。すっごい簡単です。
実態はTomcat Embeddedも入ってるので、デフォルトだと8080番ポートで起動してきます。
起動して、URLでアクセスすると、下記のような感じになります。
アカウントID、アクセスキー・シークレットキーを入れてしばらくすると、メニュー画面が出てきます。
Sydneyはまだですが、ほとんどのリージョンも対応しています。まずは東京リージョンでやってみます。
この後にAppタブでアプリケーションを作ります。これが各オートスケールグループやELBなどを管理する最も大きな構成単位になります。
このあたりはBeanstalkと少しかぶるのかもしれません。Appタブから適当に入力していけばアプリケーションは作成できます。
では肝心のオートスケールグループの作成部分をやってみます。
もう画面がついているだけで相当楽ですね。
しかもオートスケーリンググループへの変更を変更管理して、デプロイするアプリやAMI、オートスケール設定などを変更させて、その上で元のオートスケールしたインスタンスを落とすようなことが出来るようになります。例えばアプリケーションがバージョン1からバージョン2へ移行するのに、AMIが変更があったとしても、その変更をAsgard経由で管理することが出来ます。やり方としてはELBの下に一時期に2倍のインスタンスがぶらさがる形になりますが、現状からの変更をきちんと見定めたうえで旧バージョンをターミネートできる極めて現実的なやり方だと言えます。オートスケールは動的な部分の管理が多くなるのでこのような変更管理の側面をきちんと抑えているのはとても良くできていると思います。
その他にもオートスケールでの実際のアクティビティをブラウザ上からみたりと結構至れり尽くせりな感じです。
とはいえ、たまにこんなエラーもあってそこはご愛嬌ですｗ
Asgard結構よいですのでぜひ使ってみてください！
Have Fun!!!
AWS CLI補足
どうも出力情報のところが解せないので、調べてみたところ、CLIコードのREADMEにJSON使う場合には、jqなど使うといいよと書いてある。
JQ、http://stedolan.github.com/jq/ のことらしい。
jq is a lightweight and flexible command-line JSON processor.
というわけで、使ってみた。
cd /usr/bin/
wget http://stedolan.github.com/jq/download/linux64/jq
chmod +x jq
こんな感じ。
aws ec2 describe-availability-zones |jq '.availabilityZoneInfo[0]'
カラーもついて部分を取り出せるので、大変便利。しかも早くて良い感じ。
{
"zoneName": "ap-northeast-1a",
"messageSet": [],
"regionName": "ap-northeast-1",
"zoneState": "available"
}
AWS CLIをインストール
めっちゃ簡単である。
yum -y update
easy_install pip
pip install awscli
aws helpで現状扱えるサービスを確認。
Available services:
* iam
* ses
* rds
* elb
* autoscaling
* cloudwatch
* sqs
* cloudformation
* elasticbeanstalk
* sns
* sts
* directconnect
* emr
* ec2
コードはここにあーる。ぶっちゃけboto-coreに投げてるだけにみえるｗ
git clone https://github.com/aws/aws-cli.git
当然、補完を効かせたいので、下記を実行ー
うは、すげー便利。でもJSONまんまで返ってくるので、ちょい読みにくい。最初は少し驚くかもだけど、ちゃんとテキストでも出せるので心配いらない。
[ec2-user@xxx ~]$ aws ec2 describe-availability-zones { "requestId": "79c8df0c-a46c-4319-90c8-3ed44c5d4978", "availabilityZoneInfo": [ { "zoneState": "available", "regionName": "ap-northeast-1", "messageSet": , "zoneName": "ap-northeast-1a" }, { "zoneState": "available", "regionName": "ap-northeast-1", "messageSet": , "zoneName": "ap-northeast-1b" }, { "zoneState": "available", "regionName": "ap-northeast-1", "messageSet": [], "zoneName": "ap-northeast-1c" } ] }
プログラマブルには渡しやすくなったな。
テキストでやりたいときは--output textだそうで。でふぉが何故かJSONだ。
あと、--profileでプロファイルを切り替えれるのもナイス。
というわけで本年もよろしくお願いします。
余談
というか次回書く余力がない場合のため（多分ないｗ）。Workflowの実装で、
@Override public void doSome() { client.hoge(); client.foo(); }
と書くと、並列で実行され、hoge()とfoo()の順序はその順番にはならない。順序通りにしたい場合は、
@Override public void doSome() { Promise<Void> hoge = client.hoge(); executeFoo(hoge); } @Asynchronous void executeFoo(Promise<Void> hoge) { client.foo(); }
こうです。PromiseはFutureみたいなもんだけど、ノンブロッキングで結果が戻るまで待たないFlowでの基本単位です。
SWFを動かしてみる
なんかまわりがきちんとブログ書いているのを見て、たまには書いてやろうと思った次第です。訳あって、AWS Simple Work Flowを動かして色々検証しています。SWFを一言でいうなら、非同期かつノンブロッキングなやりとりが含まれる複数コンポーネント間でのワークフローを比較的楽に書くためのサービス。それなりに奥が深いのと、実際に日本語の情報が皆無なので、ひとまず動かすところまででも晒してみようと思います(先に続くかわからない・・・)。
動かす言語はJavaにするので、他言語の人はすまん。ちなみにフレームワークも利用します。AWSが出しているFlow Frameworkで、こいつはSWFを使うのを(多分)楽にしてくれる。SWF自体はワークフローサービス(というかワークフローに伴う状態管理サービスが実態に近い)なので、HTTPコールさえできればどの言語からも利用可能ではあるはず。ただし多分大変。誰かRubyとかPythonでやってる人がいたらぜひコードとかみたいです。
Flowのベーシックな仕組み
Flow FrameworkはJavaのAPTとAOPライブラリであるAspectJを使って、コードの自動生成とコードのバイトコードエンハンスを行います。なので、まずAPTおよびAspectJが動くようにEclipseの設定を行う必要があります。詳細はこちらを見てくださいな。
コンセプト図、これだけだと何かわからなそうだけど・・・ｗ
環境構築
さて、まずは環境構築をします。必要なものは、
1年目の終わりに思うこと part2
続き。
ここからは入ってからの話。
2月に入りAWSに入社して、早々にシアトルに出張になった。色々なトレーニングがあるかと思いきや、自分の時はシアトルで実際の仕事のお手伝いをするのが主になった。お客さんの名前はかけないけど、誰もが知ってるような企業での利用を実際に目の当たりにすることになって、しかも桁違いの使い方をする。それは本当に面白い体験だった。自分の中にこのくらいの規模だとこれくらいのリソースを使う、こういう使い方をする、そういうのが腹に落ちた瞬間だった。
出張中にはこんなこともあった。ある日、ホットドッグを買おうと並んでいたら、やたらよくしゃべる人がいるなあと思って後ろを振り返ると僕の上司とJames Hamiltonがいた。時間は正確にはわからないけど、そこから15分くらいデータベースや分散コンピューティングの話をしたのを覚えている。また、有名・無名関わらず、本当に抜群に頭が良い人がいる、そして謙虚であるという事を目の当たりにした最初の出張だったように思う。特に何人かの人には本当によくしてもらっていて、色々教えてもらっている。いつか与える側にまわれればと思う。
また出張中だけでなく、今もだけど、社内リソースをふんだんに活用して、表層だけではない中身を理解するようにしている。コンセプト・もたらす価値・仕組み・詳細を理解しようと。無茶苦茶社内リソースとかは見ていると思う。正直それはエキサイティングなことだし、全然苦痛じゃない。今でもまだわからない事も多いけど。クラウドが今更どうこう言うつもりはないけど、ひとつだけ言うとすれば論文などを含むパブリックなドキュメントや表層の動きだけではわからないことが色々あるのを肌で感じている。別にAWSに限った話ではなく、実際に動いている・使われているものを見ないと本当にスケーラビリティが求められる環境がどのように動くかは体験できないとは思うし、何よりそれで高いレベルでサービスが出来ていることは知れば知るほど驚きだった。
3月から東京リージョンが開設し、すぐに震災が訪れた。多くの人命が失われた震災、および原子力発電所の悲劇は言葉がない。いまでも日本は復興していないし、今後もしばらくは痛みを伴う。出来るだけのことはしたいと思う。
4月からはもう忙しいにつきる。正直気が付いたら1年経っていた。
最初の頃は、行ってみたら椅子がないようなベンチャーから誰もが知る大規模なお客さんまで色々行った。カオス真っただ中だった。あまりの違いに1日のスケジュールを見てニヤニヤしてしまう日もあった。レンタカーを返すところから新幹線乗るまで5分しかない、そんなこともあった(地方めぐり)。その中でも徐々にAWSの人数も増えてきて、比較的規模の大きなお客さんを担当する事が多くなった。得てして利用には慎重なお客さんが多い。ただその中でも利用しようとしてくれている人、口調は厳しいがちゃんと課題をくれる好意的な人がいて、そこを丁寧にやるしかないと思っていた。時間はかかる。
あと、エンタープライズのお客さんとひとくくりにするのは正直あまり好きじゃない。抱えている課題が全然違うし、本質を見失うと思う。そもそもそういう切り分けはエンタープライズとソーシャルアプリケーションという二極軸にしたいバズワードにしか聞こえない。どちらのお客さんにとっても失礼な話だと思う。課題はお客さん毎に違う、そういう心持ちで今後もいたい。
とはいえ、比較的規模の大きなお客さんを業種によらず訪問してたので、大きくざっくりと日本のお客さんの感覚が少しはつかめるようになってきていた。今までは開発サイドだけが主体だったけど、ビジネス判断でしかできないジャッジが多いことがよくわかるようになった。その中でも、こういう技術で取り組むと効果的だ、そういう感覚を得られたのは大きい気がしている。加えて、お客さんの中に本当にスマートな人がいた事が自分には本当に刺激になっている。概してそういうスマートな人は見る視点が全然違ったし、合理的だ。こういった人たちの意思決定の迅速さと方向性のつけ方が企業の基礎体力に直結しているように思う。勿論ぐうの音も出ない宿題ももらったりもしたけども（当然内緒である）。そうこうしているうちに、企業の中には必ずああいうスマートな人達がいて、そういう人にはAWSはある一定の価値がもたらせることも経験的にわかっていた。中には（ちゃんとした）クラウドが明らかにセキュアかつ経済合理的なことはわかっているし、あとは自社の導入時期だけの問題と言い切る人もいた。
余談だけど、ちなみにそういう方々はSIおよび今までのベンダがどうやって金をとってきたかをよくわかっている。きちんとユーザ目線で見合ったものを提供しているところは問題ない。しかし、そうではないと少しでも思うなら、いろいろ考えて早く動いた方がいい。現状"つけにしてもらっている"という感覚をもっていないと、本当に危ないと思う。ユーザさんも生き残りに必死だ。それを腹におちて考えて行動しているかどうか、エンドユーザ目線で言うとクラウドどうこうではなくそこに尽きると思う。
同僚も増えていった。僕と同じ職種にある人達(@ar1、@c9katayama、@understeer、@gentaw0)も人数が増えていった。勿論日本だけではない。ここまでダイナミックに変わっているのは本当に良い経験だし、なかなか得られない事だと素直に思う。勿論カオスな部分もあるけど、それを（大部分は）楽しんではいる。今年は昨年ほどはそういうカオスが少なくなりそうで若干さみしくもある。組織としてはそれで間違っていないとも思うけども。
使われるテクノロジーも変わる。基礎が大事なのは言うまでもない。表層に惑わされるのもたまには良いけど、基礎がわかっていないとなかなか先に進めない。それを踏まえたうえで色々変わっていくと思う。その一つの中核はプログラマブルなインフラ、しかも開発者一人一人がいつでも使えるようなプログラマブルインフラが破壊的なイノベーションだと思う(勿論AWSだけではない)。もっと言えばオープンソース+プログラマブルなインフラ。開発と運用の垣根が徹底した自動化で大幅に無くなることで、運用管理部分もほぼインフラの出来るプログラマ（またはプログラムの書けるインフラエンジニア）だけで行えるようになる事は、エンドのお客さんにとっては福音に思える。もう一つは分散コンピューティングのテクノロジ。ようやくそれが実現できるインフラが誰でも入手できるようになってきている事が素晴らしいことだと思う。多くの人がうまく活用できるようになればと思う。他にも今年も大きく変わっていくんだろうと思うし、個人的には何かそういうものを作ったり試せればと思う。
1年振り返ってみて、何より経験する事を最優先してきたように思う。そもそも今の会社へ来る最大の決め手も経験することだった。別に日本企業が悪いと言ってるわけではない。あくまで個人的に経験してみたいという極めて主観的な欲求に従っただけだし、今のところそれでよかったと思っている。勿論失ったものがないわけじゃないけど、そこはトレードオフなので飲み込んでおく。もう若くないけども、2012年もそうありたい。
1年目の終わりに思うこと part1
出張でシアトルに来ている。ようやく自分の時間が出来たので、だいぶ時間が経ってしまったが少しこの1年とそれ以前を振り返ってみる。ほぼ自分のために書いている。もう時効だから書いてもよいかと思って色々書いてみる。
昨年の2月から今の現職で働いている。たった1年だけど、時間的にはより多くの時間を費やしているように思う。気分的には3年くらい。未来を先取りしているようなところも正直ある。時間が早いのは実は仕事だけではなくて生活や家庭面での変化も大きい。特に個人の時間の取り方もそうだったりする。そしてこれら全部合わせて、非常に多くの事が変わった。
最初は正直かなり不安だった。今まで所謂外資企業で働いたことはない（そういったところとも明らかに違うのだけども）。加えて、今までのような職種ではなく、よりお客さんのところに行く回数が多い。自分がアジャストできるか、というのもあった。細かいものであれば色々ある。英語とかも勿論。今となっては、もういいや・どんとこーい！で飛び込んだ感じでそれが結果的にまわりが助けてくれたのでよかったのかも。
実はAWS(正確にはAmazon Data Service Japanだけど)で働くことを考え始めたのは、ずいぶん前にさかのぼる。まずは最初にそのあたりを書いてみたい。意識したのは小島さんが転職した時なので2009年12月。最初に考えたのは多分2010年の3月あたり。クラウドコンピューティングが全てではないことは勿論理解しつつも、分散コンピューティングを中心としたテクノロジでサービスを展開するAWSは、非常に多くの事が実現できる・今までやれていなかった事を出来る可能性を感じていたし、何よりとても面白そうだった。そこから色々調べた。AWSの持つ文化、何を今まで実現してきたか、何が違うのか、強みは何か、弱みは何か、そこで働く人はどんな人か、お客さんはどうして使うのかなどなど。調べれば調べるほど違うと感じた。そもそもITの会社じゃない。発想は小売りの地をいくような考え方でITを使っているだけ、そう思った。実際今でもそう思う。でも何よりその技術の素晴らしさ・方向性には感動した。
実際に動き出したきっかけはUSから今と同じ職種(といっても全然偉い)のPaulが日本でトレーニングをするので、それを受けたとき。トレーニングの内容は結構知らない人にとってはハードだったように思う。EC2からVPCまで一通りのサービスを2日間でやりきるというものだった。でも予習をしていたので、自分だけ知りたくて質問しまくった。そろそろいい加減にしたらってまわりに変な目でみられても気にならなかったｗ。
受けるのを決めたのは忘れもしない、沖縄での休暇中。勿論誰にも話してはない。嫁に転職したいという話をするのが裏の目標で沖縄に旅行に行った。はっきりいえば家庭内プレゼンであるｗ 長い交渉の末オッケーをもらった。そのときに、TwitterのDMが小島さんから来ていた。
AWSをうけてみませんか？
なんだか何かにひっぱられていると思った。とはいえこのチャレンジはしてみるべきだ、そういう直感があった。
（続く）
