2012年12月29日土曜日

本年の出社おわり

やることは沢山あるのだが、31日出社する気にはならんのでひとまず今年のしごとおさめということにする。

昨年に引き続き今年もその月何してたか、当たり障りのないもののなかから、まとめてみる。

  1. DirectConnectの準備が忙しかった。毎週固定でやる重いミーティング3並列が3ヶ月目でかなり辛くなってくる。
  2. シアトルでのセールス大集合+トレーニングがとてもよかった。しかしこの時しこんだことは実現せず。大変だったのに。
  3. 4月以降の布石的な話を聞くことが増える。東京リージョン1年ってこういうこと。
  4. 新大阪出張案件に行くときに、新幹線にのってる芸能人を初めて見る。
  5. DirectConnectの具体的な導入の話が増えてくる
  6. JAWS−UG東京のデータベースナイトイベント!
  7. ゲーム以外での突発イベント系の話が増えてくる
  8. サンフランシスコ出張。HP辞めて以来、もう来ると思ってなかったし、HPのときはパロアルト直行だったので夏こんなに涼しいなんて知らなかった。
  9. 1年前からやってるデカイ案件がいよいよローンチ。で、大変だったがなんとか。
  10. 客先から客先の時間がまにあわずタクシーを使う、という経験を初めてやる。
  11. Re:Invent参加できなかった!
  12. ますますUS東海岸にしかないものが欲しくなる1年でした

昨年にくらべれば、随分オフィスにいられる時間は長くなった。とはいえ、あいかわらず検証や実験の類の時間は土日や夜間になってしまうし、時差もあるしでキッチリ時間を切ることは無理なことは相変わらず。

2012年12月24日月曜日

CDPアンチパターンの14つめはバックアップのアンチパターン

今年のクラウドデザインパターンの最大のイベントといえば、ラスベガスでの英語における発表だったでしょう。しかし、東京お台場で9月に行われたクラウドデザインパターンの発表もすばらしいものばかりでした。

そこで、私はアンチパターンのワースト13を発表しました。そのプレゼンの中でも発表しましたが、アンチパターンの目的はただ笑うためにあるものではありません。

  • 失敗に陥るパターンを類型化し、事例の早期発見と対応策に関しての提案を目的とする。
  • 動作やプロセス、構造について、当初は妥当であったのに、最終的に悪い結果が繰り返されるパターン
  • リファクタリングするための方法が存在するパターン

この3つの観点をわすれてはならないと思っています。

13のアンチパータンの後ろに続くワーストは、バックアップにかかわるものばかりでした。特に、AWSでバックアップを考えるとき便利なのはAMI、EBSとスナップショット機能でしょう。

  • 「AMIを一切作らずに本番運用を行う」ことがしばしば見受けられます。これはAMI作りが難しいと思っている場合や、OSからの手順に固執した場合などに見られがちです。ある程度のところまでAMIの形でシステムを用意しておけば、システム構築やトラブル時の対応時間の短縮が可能です。
  • 逆に「AMI作成だけがバックアップ」だと思っているとすれば、それも問題です。AMI作成の最大の問題は、AMI作成を動作中に安全に行うことができないことです。また、EBSを使わない場合にはバックアップできないと思っているとすればさらに問題です。
  • 「スナップショットを使わない」ことも問題です。EBSによるバックアップは残念ながら完璧ではありません。AWSはEBSが壊れかねないことを表明しています。スナップショットを使えば、異なるアベイラビリティゾーンへの移動や、操作ミスによるファイル消失リスクを下げることもできます。
  • 「スナップショットを安全に使えない、使わない」のも時として問題です。EBSはあくまでボリュームでありそのファイルシステムやアプリケーションでキャッシュしている内容はわかりません。スナップショットをバックアップに使うのであれば、ボリュームへの書き込みを確実におこなわければなりません。

繰り返しになりますが、AMI,EBS,スナップショットはAWSでのシステム運用に大きく貢献できる機能です。ぜひこれらの特性を理解して利用しましょう。

さて、13のアンチパターンを見たことがないひとのために復習をしておきます。

  1. プロトタイプを作らずに机上だけで設計を行う
  2. トラフィック代金を心配しすぎる
  3. IPアドレスに頼りすぎる
  4. ひとつのアベイラビリティゾーンだけでシステムを作る
  5. EC2以外のサービスを使わない
  6. S3を共有ストレージ、ブロックストレージとして使う
  7. 事前のキャパシティプランニングに固執する
  8. AWSのセキュリティ機能を使わない
  9. 構築したシステムの見直しをしない
  10. 全機能を使おうとして消化不良に陥る
  11. リージョン選択を間違う
  12. CloudFrontを使わない
  13. 実際の負荷変化と違う負荷テストを行う

中でも、机上の設計だけで本番のシステムを決めてしまうことだけは避けましょう!AWSはまだまだ発展していくシステムです。

そして、逆説的ですが、CDPに固執することなく新たなアーキテクチャに挑戦していきましょう。

[slideshare id=14541803&w=427&h=356]


2012年12月6日木曜日

VPCのメタパターンもしくは怠惰な私のVPC導入。

皆様、昨日の松井さんの男気あふれる記事に度肝を抜かれた荒木でございます。毎度のことながら彼の軌跡は奇跡として語り継がれるといって間違いないでしょう。

さて、VPC環境構築のメタパターンと予告しました。実際のところCloudformationの出番は無限です。その中でも最も強力なのは、ある状態を保存再現する機能です。VPCのように面倒な環境構築に有効です。

時間のない人のために結論を。

  1. CloudFormationはある時点の状態再現に有効です。
  2. VPCに関しては再現を自動化するのは諦めて、(時としてつまらない)設計を再現するためにCloudFormationを使いましょう。
  3. 実はVPCIDを使えばClassicな環境からの移行は簡単!

というわけで、CloudFormationこそがVPC導入のポイントかもしれません。

これから述べる内容は

  1. ELB
  2. アプリケーションサーバ
  3. データベース(RDS)

のどこにでもある三段構えのサービスを題材にしています。

CloudFormationの意義

AWSを使ったシステム構成工数に関しては多くの方が考える問題です。
システムは机上での設計ではなく、試行錯誤を経てサービスを作るべきだとは思います。

実際のシステムでは、構成変更時にはテストが欠かせません。
また、テストの与える影響の測定や変更前への切り戻しを意識したシステム構成を求められることはまちがいありません。
そのために同一のシステムを構成し、部分的な変更を加えた後にテストを行うのが理想的な体制でしょう!

その一方で、この師走のなか、毎回同じことを繰り返す時間はない、というのが本当のところではないでしょうか。
何度でも速やかに構成(クローニング)できるようにして、ある時点でのシステムにもどせれば、どんどんチャレンジすることができるはずです。

そこで役に立つのがCloudFormationです。

テンプレート作成には3つの方法があります。

  • テンプレートの文法をAWS CloudFormation User Guideを読み、いちから作成する方法
  • AWS CloudFormationサンプルテンプレート(http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/) として集められたサンプルを流用する方法
  • CloudFormerを使って、既存のAWSリソースからCloudFormationテンプレートを作成する方法

正直、最初の2つの方法は「部分的に変更を加えてきたシステム」において現実的な方法ではないでしょう。そこで3番目のCloudFormerの登場です。

一旦、CloudFormer で作成した AWS CloudFormation テンプレートを使うと、AWS Management Consoleで数回クリックするだけで既存のシステムのコピーを起動可能です。

準備:まずは、CloudFormer自体を用意する。

https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-1#cstack=sn~AWSCloudFormer|turl~https://s3.amazonaws.com/cloudformation-samples-ap-northeast-1/AWSCloudFormer.templateをクリックして、早速使ってみましょう。

起動すると、次のような画面があらわれるはずです。

CF first

CloudFormerはIAMのアカウントを使用するため、その確認のチェックはさくっと終わらせて前にすすみましょう。



すると、こんな具合で最終的にシステムを作っていいかどうかの確認がはいります。もちろん躊躇せずにContinueしましょう。



無事起動するとStatusがCREATE_COMPLETEに変わります。それまでは、Eventsでもみてニヤニヤしましょう。

CloudFormerの使用

CloudFormerを使用するには、CloudFormerの作成したURLにwebブラウザでアクセスします。そのURLはOutputsタブの中で確認します。



するとこんな画面があらわれます。テンプレート作成対象リージョンを選択しましょう。



あとは一本道です!

含めるドメイン名を確認したり、EC2を確認したり、RDSを確認したり、セキュリティグループを確認したり。。

数個の画面でチェックをつづけると、S3に保存するように促されます。保存されたテンプレートはJSON形式で、その頭のほうが確認できます。



ここまできたら、このテンプレートをつかってたちあげてみましょう。Congratulationsがきたら、即座にLaunch Stackです。



とはいえみなさん時間もないことですし、上がりそうだ!という雰囲気だけつかんでおきましょうか。



とりあえず、作成したテンプレートの置き場だけは確認しておきましょう。このテンプレートがスタート地点になります。

とはいえ、これで完璧か!といわれるとそんなことはありません。

CloudFormerはまりポイント1:AMIは動作時インタンスのAMIである

個人的にCloudFormerのハマリポイントはなんだと問われれば、AMI情報は動作時のインスタンスが起動した時点でのAMIであって、CloudFormerがAMIを作るわけではないところです。

    "instancei2d5f6a2d": {
"Type": "AWS::EC2::Instance",
"Properties": {
"AvailabilityZone": "ap-northeast-1b",
"DisableApiTermination": "FALSE",
"ImageId": "ami-c857e5c9",
"InstanceType": "m1.small",
(以下略)

こんなテンプレートがあるときは、このAMIの内容を変更したならば、自分でつくりなおさなければなりません。あえてつくりなおさなければならないときは、マネージメントコンソールでインスタンスから右クリックして作りなおせばよいでしょう。

CloudFormerはまりポイント2:Route53で指定している値は動作時ELBのCNAMEである

こう言われてもピンとこないかもしれません。

    "dnscdpshoparakiin": {
"Type": "AWS::Route53::RecordSet",
"Properties": {
"HostedZoneId": "/hostedzone/xxxxxxxxxxxx",
"Name": "xxxxxxx.araki.in.",
"Type": "CNAME",
"TTL": "300",
"Comment": "araki.in ",
"ResourceRecords": [
"xxxxxxx-444735762.ap-northeast-1.elb.amazonaws.com"
]
}
},

この、ResourceRecordsの内容はそのものずばりELBのCNAMEを指定しています。
このままでは、ELBの定義ではなく、ELBのエンドポイントそのものを指定しているため、作成したELBからFn::GetAttを使って値を得る形式に変更します。
例えばこんな具合に。

{ "Fn::GetAtt" : [ "elbeccube", "DNSName" ] }

CloudFormerはまりポイント3:RDSの内容は動作時である

これもELBと同じですが、データが消えるという意味ではもっと問題がおおきいかもしれません。

スナップショットを作成したら、DBSnapshotIdentifierパラメータで指定しましょう。

CloudFormerはまりポイント4:手修正でフォーマットを破壊する

ここまでうまく行っても、人間にはJSONやSGMLやXMLは無理だという説があります!

もちろん慎重にやれとか、ダブルチェックしろとか、トリプルチェックしろ。。N重チェックというループに陥いるのもいとおかしというところですが、そんなくだらないチェックには機械にやらせましょう。

そこで登場するのがcfn-validate-templateコマンドです。

$ cfn-validate-template –template-file テンプレートファイル名

で、テンプレートがValidと言われるまでこころのままに修正しましょう。

今時の人なら、こんなコマンドよりもVisualなアプローチのほうがいいかもしれません。たとえばMacならVisualJSONをつかってみましょう。構造も一発で確認できます。

クローニング実行

それでは準備したCloudformationを実行してみましょう。
クローニングの実行は、CloudFormationのタブ内、Create New Stackボタンを押すところからはじまります。



つづいてStackNameとJSONファイルの在り処を指定します。



後は、CloudFormation Stacksの画面から、Statusの変化と、Eventsの出力適宜Refreshしながら眺めて待ちましょう。

CloudFormationではカバーできない部分のフォローにUserData

CloudFormationによって骨格はほぼ完成したもののたとえば、アプリケーション固有の設定はカバーできません。
ここで登場するのが、UserDataです。

      "instanceib3ba90b3": {
"Type": "AWS::EC2::Instance",
"Properties": {
"AvailabilityZone": "ap-northeast-1a",
"DisableApiTermination": "FALSE",
"ImageId": "ami-5259eb53",
"UserData": { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash \n",
"sed -i \"s/yyyyyy.araki.in/",
{"Ref":"SiteURL"},
"/g\" /home/ec2-user/cdp/eccube/data/config/config.php\n",
"#EOF"
]]}},

この例では、/home/ec2-user/cdp/eccube/data/config/config.php に含まれる yyyyyy.araki.inをSiteURLというリファレンスに書き換えています。ある意味かなり力技ですが、UserDataの万能感は異常です。

VPCに関しては再現を自動化するのは諦めて、(時としてつまらない)設計を再現するためにCloudFormationを使いましょう。

とまあ、こんなことを書くのは、CloudFormerがVPCに対応していない試行錯誤したシステムの保存にフォーカスしていて、なおかつ、繰り返し単調な設計がつづくネットワーク再現に最適だからなのです。

たとえば、こんなことやってられますか?

1        VPCとして10.1.0.0/16を定義 

2        ELB用にPublicサブネットを定義 

2.1       ZoneAELBsubnet 10.1.10.0/24を定義

2.2       ZoneBELB subnet 10.1.11.0/24を定義

3        eccube用にPrivateサブネットを定義

3.1       ZoneAeccubesubnet 10.1.20.0/24を定義

3.2       ZoneBeccube subnet 10.1.21.0/24を定義

4        RDS用にPrivateサブネットを定義

4.1       ZoneARDSsubnet 10.1.30.0/24を定義

4.2       ZoneBRDS subnet 10.1.31.0/24を定義

5        インターネットゲートウェイを定義

5.1       インターネットゲートウェイをVPCに関連づけ

6        2Publicサブネットの経路表を定義

6.1       Publicサブネットの経路表にデフォルトゲートウェイとしてインターネットゲートウェイを向ける

6.2       ZoneAELBsubnetに対して経路表を関連づけ

6.3       ZoneBELBsubnetに対して経路表を関連づけ

7        2PublicサブネットにNACLを定義

7.1       Inbound用にHTTPポートを許可

7.2       Inbound用に1024から65535のダイナミックポートを許可

7.3       Outbound用にHTTPポートを許可

7.4       Outbound用に1024から65535のダイナミックポートを許可

7.5       ZoneAELBsubnetに対してNACLを関連づけ

7.6       ZoneBELBsubnetに対してNACLを関連づけ

8        PrivateサブネットにNACLを定義

8.1       Inbound用にVPC内部からの接続を許可

8.2       Outbound用にVPC内部への接続を許可

8.3       ZoneAeccubesubnetNACLを関連づけ

8.4       ZoneBeccubesubnetNACLを関連づけ

8.5       ZoneARDSsubnetNACLを関連づけ

8.6       ZoneBRDSsubnetNACLを関連づけ

 

 



あたまがクラクラしてきませんか? 正直私はこんな指示書を渡されて、マネージメントコンソールから設定しろと言われたらいやになります。正直いくららくらくページを稼げるといわれてもスクリーンショットなんてとってられません。

一方で、こういう繰り返しはCloudFormationならばコピペ一発です。なんという楽でしょう。しかも失敗もへります!

もっとも、コピペの結果はこんなダラダラとしたJSONになります。

VPCの中へのサービス配置

VPC内部のサブネット作成が完了したら、実際のサービス配置をはじめます。

CloudFormationテンプレートの入れ子呼び出し

まず最初のテクニックは、VPCサブネットを作成するために使ったCloudFormationテンプレートの呼び出しです。
呼び出しは、AWS::CloudFormation::StackのPropertiesにTemplateURLとして与えます。

    "Resources" : {
"vpcMake" : {
"Type" : "AWS::CloudFormation::Stack",
"Properties" : {
"TemplateURL" : "https://s3-ap-northeast-1.amazonaws.com/arakisa
/CloudFormation/eccube-vpc-05vpc.json",
"TimeoutInMinutes" : "60"
}
},

このテンプレートでは、呼び出し元となるCloudFormationテンプレートに実行結果の値を渡すために、Outputsを定義しています。

    "Outputs":{
"ELBSubnetAId":{
"Value":{"Ref": "ELBSubnetA"},
"Description":"Id of ELBSubnetA"
},
"ELBSubnetBId":{
"Value":{"Ref": "ELBSubnetB"},
"Description":"Id of ELBSubnetB"
},
"ECSubnetAId":{
"Value":{"Ref": "ECSubnetA"},
"Description":"Id of ECSubnetA"
},
"ECSubnetBId":{
"Value":{"Ref": "ECSubnetB"},
"Description":"Id of ECSubnetB"
},
"RDSSubnetAId":{
"Value":{"Ref": "RDSSubnetA"},
"Description":"Id of RDSSubnetA"
},
"RDSSubnetBId":{
"Value":{"Ref": "RDSSubnetB"},
"Description":"Id of RDSSubnetB"
},
"VPCID":{
"Value":{ "Ref" : "VPC" },
"Description":"Id of VPC"
}
}

たとえばこんな具合です。ネットワークに関連するIdをVPCID, ELBSubnetAId, ELBSubnetBId, ECSubnetAId, ECSubnetBId, RDSSubnetAId, RDSSubentBIdとして定義しています。

呼び出し元で上のVPCIDを使うためには、

{ "Fn::GetAtt" :["vpcMake", "Outputs.VPCID"] }

のように、Fn::GetAttを使っていつでも呼び出すことができます。

呼び出し元テンプレートの修正

親となるCloudFormationテンプレートでは、VPC環境に対応した修正が必要です。
今回、VPC内で使用を定義するために特別なパラメータをあたえなければならないリソースタイプは

  • AWS::ElasticLoadBalancing::LoadBalancer
  • AWS::EC2::SecurityGroup
  • AWS::EC2::Instance
  • AWS::RDS::DBSubnetGroup
  • AWS::RDS::DBSecurityGroup

という5つです。

AWS::ElasticLoadBalancing::LoadBalancer

ELBはVPCにおいては、配置するサブネットと、セキュリティグループを指定します。
ELBを配置するサブネットの指定は、AWS::ElasticLoadBalancing::LoadBalancerの中で、Subnetsで指定し、セキュリティグループも同様にSecurityGroupsとして指定する。

        "elbeccube": {
"Type": "AWS::ElasticLoadBalancing::LoadBalancer",
"Properties": {
"Subnets": [
{ "Fn::GetAtt" :["vpcMake", "Outputs.ELBSubnetAId"] },
{ "Fn::GetAtt" :["vpcMake", "Outputs.ELBSubnetBId"] }
],
"SecurityGroups" : [{"Ref" : "LoadBalancerSecurityGroup"}],
……(略)

AWS::EC2::SecurityGroup

セキュリティグループは、AWS::EC2::SecurityGroupを使って指定します。
VPC内においては、セキュリティグループも、どのVPCに所属しているかをProperties中にVpcIdとして宣言します。

       "LoadBalancerSecurityGroup" : {
"Type" : "AWS::EC2::SecurityGroup",
"Properties" : {
"GroupDescription" : "Enable HTTP access on port 80",
"VpcId" : { "Fn::GetAtt" :["vpcMake", "Outputs.VPCID"] },
"SecurityGroupIngress" : [ { "IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0" } ],
"SecurityGroupEgress" : [ { "IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0" } ]}},

AWS::EC2::Instance

EC2インスタンスもVPC内で起動させるためには、SubnetIdを指定します。

        "instanceib3ba90b3": {
"Type": "AWS::EC2::Instance",
"Properties": {
    "SubnetId": {"Fn::GetAtt":["vpcMake", "Outputs.ECSubnetAId"]},
…… (略)

AWS::RDS::DBSubnetGroup

RDSが使用するサブネットにはSubnetIdを指定します。

       "MyDBSubnetGroup" : {
"Type" : "AWS::RDS::DBSubnetGroup",
"Properties" : {
"DBSubnetGroupDescription" : "Subnets available for the RDS DB Instance",
"SubnetIds" : [
{ "Fn::GetAtt" :["vpcMake", "Outputs.RDSSubnetAId"] },
{ "Fn::GetAtt" :["vpcMake", "Outputs.RDSSubnetBId"] }
]}},

AWS::RDS::DBSecurityGroup

RDSはさらにDBSecurityGroupも定義します。この例では、CIDRブロックを使っています。

        "dbsgdefault": {
"Type": "AWS::RDS::DBSecurityGroup",
"Properties":{
"GroupDescription": "RDS security group in private",
"EC2VpcId" : { "Fn::GetAtt" :["vpcMake", "Outputs.VPCID"] },
"DBSecurityGroupIngress": [{
"CIDRIP": "10.1.20.0/23"
} ]}}

以上の修正を加えたCloudFormationテンプレートを
https://arakisa.s3.amazonaws.com/CloudFormation/eccube-vpc-06instance.json
に置いておきます!ながーいのでニヤニヤする程度にとどめてくださいませ!

結論

  1. CloudFormationはある時点の状態再現に有効です。
  2. VPCに関しては再現を自動化するのは諦めて、(時としてつまらない)設計を再現するためにCloudFormationを使いましょう。
  3. 実はVPCIDを使えばClassicな環境からの移行は簡単!

というわけで、CloudFormationこそがVPC導入のポイントです。異論は大いにあるでしょうけれども、今あるシステムを移行するほうが新規に設計するよりは難しいとおもいます。そんな手助けに(主に試行錯誤のためですが)なると幸いです。

2012年11月2日金曜日

スケールアウトを阻むライセンス

スケールアウトに適すのは、ソフトウェアを使うときにライセンス課金という壁を立ちはだからせず、顧客の要求にとにかく答える製品です。結論をまず書きました。

世の中スケールアウトバンザイという事ばかりではない。

なにしろそもそもスケールアウトできない実装なんていくらでもある。ひどい例だとお思いでしょうが、スケールアウトに向いた製品といわれるKVSをCookie保持に使っているのに中間状態を半端に保持してしまうアプリ実装になっていて、入り口のロードバランサでStickness保持なんてこともある。

とはいえ、技術的に解決できることはいい。根が深いのはライセンスによるもの。

スケールアウトに向かないライセンスはこんなところだろう。

  • 起動するサーバのMACアドレスを予め決めておくもの。
  • サーバが起動する毎に一時鍵が発行され、それをライセンス元に送って認証するもの。認証に数時間から数日かかるもの。
  • サーバの起動時に様々な関係のない情報をスキャンし、ちょっとでも変わっていると新規ライセンスを必要とするもの。
  • 動作するサーバをそもそも決めてしまう(サーバにメーカーでインストールして出荷するアプライアンスになっているが、その中身はx86どころがESXiだったりHyperVだったりするもの)

「スケールアウトで何とかしよう」という考えは時間の余裕がないときにいかんなく発揮される。目の前の問題を「スケールアウトで何とかしよう」と思って、なんとかできそうなのに、ライセンス理由でスケールアウトできない、あるいは時間がかかるものは全てダメだろう。

まあ、どんなライセンスにしようと、その権利を持っている人が自由に決めればいいといえばいい。

一方で、次の通りスケールアウトと馴染みのいいライセンスと比べると、使われなくなっても仕方がないだろう。

  • 自由に使っていいライセンス。例えばDebian.
  • AWSの課金に上乗せされて時間単位でライセンス料金を徴収するもの。たとえばRHELやMS Windows.
  • 必要なライセンス数の数え方がどんぶり勘定なもの。

いろいろあるのだがまとめると、こんな事だと思う。

  • スケールアウトに適さないのは、ソフトウェアを使う前に課金し、課金が完了しないと動作しない(あるいは使ってはいけないとされている)製品。
  • スケールアウトに適すのは、ソフトウェアを使うときにライセンス課金という壁を立ちはだからせず、顧客の要求にとにかく答える製品。

ともかくまず全力でお客様と一緒に問題を解決しておいて、あとから金いただくというのは信頼関係や保証してくれるクレジットカードというセーフネットがあってこそのものとも言えますが。

2012年8月22日水曜日

AWSの長期保存用ストレージ。Glacier

ついに出た、やっと出た、AWSの長期保存用ストレージ。
http://aws.amazon.com/glacier/

【AWS発表】 Glacier – 1GBあたり月額約1円で利用可能なアーカイブストレージが登場 - Amazon Web Services ブログ

Glacier – 1GBあたり月額約1円で利用可能なアーカイブストレージが登場 本日AWSはまた新たなサービスである、Glacierをロウンチしました!

ってことで、AWS公式ブログにも出ているように、安くて保存に向いている。

例によって、AWSにアップロードするトラフィックは無料なので、保存したままにしておくのであれば、ストレージコストだけで済む。
ダウンロードが高いというのであれば、専用線でむすぶ http://aws.amazon.com/jp/directconnect/ がある。

いろいろと周辺ツールが揃ってくるまでは様子見という人も多いとは思う。それはそれでいいので、こんなのが欲しい、こんなの作ったぜを集めていきたい。

[youtube http://www.youtube.com/watch?v=jQR9JpVKc2A&w=560&h=315]

2012年8月14日火曜日

VPCの非機能要件

Amazon Virtual Private Cloud. 略してAmazon VPC。もっと略してVPC.

VPC上でサービスを作成することは、Eコマースサイトにおいて必ずしも必要なことではない。利用コストはかからないが、利用するためには知識習得コストもかかる。

一方で、VPCでのみ提供されているサービスを使うために、あるいはVPCでなければ満たせない法令や業界団体等で定めた基準といった非機能要件を満たすために、VPC上でのサービス作成が有効な場合は多い。

 



非機能要件での典型的な例は、国際ペイメント業者5社が共同で作成したクレジット業界におけるグローバスセキュリティ基準であるPCI DSS(Payment Card Industry Data Security Standard)の取得である。PCI DSSは情報セキュリティに対する具体的な実装や施策を要求しており、クレジットカード情報と全く関係ない企業や組織ですらPCI DSSを基準とした情報安全対策を求められることが増えている。

PCI DSSの基準には、”Build and maintain a secure network”なる条項がある。VPCはinboundだけではなくoutboundの制御もできたり、インターネットゲートウェイでアクセス制御ができたり、サーバの種別毎にサブネットを分けたりできる。VPCを使うことで、この条項を満たすことを説明することが容易になることから、VPCを利用されることが多い。

AWSが認証されているPCI DSS準拠のPCIサービスプロバイダ(レベル1)の意味は、独立した認証審査期間であるQSA(Qualified Security Assessor)が、PCI DSS v2に対してAWSが準拠しているということを認証しているという意味である。

つまり、このEコマースがAWSを利用してシステム開発しておけば、インフラストラクチャはPCI準拠しているので、AWSが提供する部分以外の部分にPCI DSS取得の努力を集中させることができる。

2012年7月18日水曜日

なぜVPCなのか: それは説明が楽だから。

VPC上でサービスを作成することは、Eコマースサイトにおいて必ずしも必要なことではない。その一方で、VPCでなければ満たせない各種の基準を満たすため、各種のサービスを使うために、VPC上にサービスを作成することはおおきなメリット。

「基準を満たすため」の典型的な例は、国際ペイメント業者5社が共同で作成したクレジット業界におけるグローバスセキュリティ基準であるPCIDSS(Payment Card Industry Data Security Standard)の取得。PCIDSSは情報セキュリティに対する具体的な実装や施策を要求しており、クレジットカード情報と全く関係ない企業や組織ですらPCIDSSを基準とした情報安全対策を求められることが増えています。

その中には、"Build and maintain a secure network" なる条項があり、VPCはinboundだけではなくoutboundの制御もでき、さらにインターネットゲートウェイでNACLをかけることができる。

AWSが認証されているPCI DSS準拠のPCIサービスプロバイダ(レベル1)の意味は、独立した認証審査期間であるQSA(Qualified Security Assessor)が、PCI DSS v2に対してAWSが準拠しているということを認証しているという意味。つまり、このEコマースがAWSを利用してシステム開発しておけば、インフラストラクチャはPCI準拠しているので、AWSが提供する部分以外の部分にPCI DSS取得の努力を集中させることができる。

こう言うことは正しい。しかしながら、QSAに対してしっかりと説明することさえできれば、QSAが決めることなので、別にVPCは必須にはならない。

「各種のサービスを使うため」についてはいよいよ沢山でてきた。

どれもこれも、ユーザにとってのAWS使用法に、より自由をもたせる機能であるといえる。

さて、このような背景で「VPC」を使わない理由を説明できますか? 説明できる方は、きっとVPCにない機能が必須なのでしょう!

2012年7月17日火曜日

AWSのデベロッパーサポートエンジニア

AWSには様々なエンジニア職があるけれども、

定時勤務はゆずれない。家庭の生活が第一。営業なにそれ美味しいの?技術でのコミュニケートならOK、というような方はAWSのDeveloper Support Engineerは一考に値する職だと思います。

これは私の職からみたイメージです。私の職には(まだ)ないものですが、それは彼らのほうが早くたちあがったからでしょうきっと。

英語も若干使えないといけないけど。。興味があるかたはご連絡を。

2012年7月7日土曜日

Private IP Addresses Per ENI Per Instance Type

VPCの中で、複数のIPアドレスを持てるようになった。

複雑なのでメモっておく。

  • micro: ENI非対応
  • small: 4
  • medium: 6
  • large: 10
  • xlarge: 15
  • 2xlarge以上: 30 (ただしcc1.4xlargeはなし)

2012年6月27日水曜日

S3のエラーハンドリングPerl編

S3は作ったばかりのバケットを扱おうとすると、307 redirectを返すことがある。他にも http://docs.amazonwebservices.com/AmazonS3/latest/API/ErrorResponses.htmlにあるように多数のエラーレスポンスは定義されている。が、3xx系は扱えないライブラリであるLWPがメインのperlの場合

CPANに登録されているAmazon::S3とNet-Amazon-S3ではこんな対応がされている。(というかここのコメント100%同じ。ライセンス的にはokだからいいんだろう)

cpansearch.perl.org/src/TIMA/Amazon-S3-0.45/lib/Amazon/S3.pm

http://cpansearch.perl.org/src/PFIG/Net-Amazon-S3-0.56/lib/Net/Amazon/S3.pm

# Send a HEAD request first, to find out if we'll be hit with a 307 redirect.
# Since currently LWP does not have true support for 100 Continue, it simply
# slams the PUT body into the socket without waiting for any possible redirect.
# Thus when we're reading from a filehandle, when LWP goes to reissue the request
# having followed the redirect, the filehandle's already been closed from the
# first time we used it. Thus, we need to probe first to find out what's going on,
# before we start sending any actual data.

ということらしい。LWPがサポートしてないが故にHEADをわざわざ発行しているという。

Perlモジュール/LWP - Walrus, Digit.

POSTメソッドの場合でもこれを行うには、正攻法であればrequest処理時に返されるHTTP::Responseオブジェクトの内容を調べます。 リダイレクトが指定されていると、HTTP::Responseオブジェクトのis_responseメソッドの返り値は1になります。 この時に、HTTP::Responseオブジェクトのheaderメソッドで'Location'に対応する値(リダイレクト先のURLです)を取得し、このURLをGET(リダイレクトはGETで行うのが標準です)すれば良いのです。

2012年6月22日金曜日

VPCでのELB活用

VPCはAWSにおいて相談だれる様々な事を解決するツールというか環境なので、みなさまには大いに活用していただきたいと思っています。
正直、今からシステムを作るならばVPCを使わない理由を探すのがむずかしいほど。



こんなことを書いた。

これを絵にするとこんな具合。

通常のEC2でのELBは、いわば共用のネットワークセグメントで動作しており、自分でELBへどんなIPからアクセスすることができる。



VPCではELBは自分専用のVPC空間の内部に作成されるため、自分が設定したNACL下で動作させることができる。

2012年6月20日水曜日

TOP500の更新

スパコン「TOP500」、米「Sequoia」が首位に--「京」は2位 - CNET Japan

最新版「TOP500」リストによると、ローレンスリバモア米国立研究所にあるIBMの「Blue Gene/Q」スーパーコンピュータである「Sequoia」が、16.32ペタフロップスを達成したという。前回首位だった「京」が10.5ペタフロップスでそれに続いた。同リストは、ハンブルグで開催されているInternational Supercomputing Conferenceにおいて現地時間6月18日に発表された。

まあそんな記事はさておき。

AmazonはTOP500の42から72位に落ちました。前回あったもうひとつの記録は今回は圏外になりました。

ネットワークに目をやると、上位はtofuにinfinibandにのオンパレード。
イーサネットだけのデータだと最速は61位のHPのクラスタで、2位がAWSでした。
その61位のクラスタがEfficiencyがたったの28。Nvidia GPGPUパワーでたたきだしたもの。

そしてGPGPU搭載モデルがことごとく上位から消えていました。

2012年6月17日日曜日

AmazonLinuxにVarnish3をいれるはなし

バグとなれば見るしかないですよねー。http://repo.varnish-cache.org/source/varnish-3.0.2.tar.gz からソースとってくる


yum install pcre-devel
configure
make
make install

これで問題ない。まあyumつかえばさくっとvarnishはいるんだけど。

結局、ヘルスチェック機能はまだ使わんでおいとこうという結論。

2012年6月15日金曜日

Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒より だいぶ長くしよう。その背景。

鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で

■AWSのELBとApacheを使う際の注意点

・Timeoutは120以上が推奨

・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。

という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok!)

根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。

ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCPセッションをつかいまわすことによってTCPのハンドシェイク時間を削減して高速化している。



webサーバのTimeoutを60秒より短かくするとどうなるか。どうかするとあわれなELBはwebサーバから切られたことを知らず、TCPセッションを使おうとして失敗することもある。折角ハンドシェイクをとばして高速化できるチャンスを逃してしまうことになる。

じゃあなんでELBでないフツーのサイトやフツーのロードバランサで構成するwebサイトにおいて「KeepAliveを無効にして、Timeoutは短かく(たとえば5秒)しよう」という言説が流れているのか。

これは、クライアントがずっとコネクションをはりっぱなしにする傾向があるから。

HTTP keep-alive connection timeouts « FastMail.FM Weblog というすばらしい記事によると、

  • Opera 11.11 – 120 seconds
  • Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
  • IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though the page only mentions IE 5/6/7)
  • Firefox 4 – 115 seconds (changeable in about:config with network.http.keep-alive.timeout preference)

といった具合。ほとんどのwebサイトにおいては、いくら通信が高速化されるとはいえ100秒も通信維持されても困ることばかりだろう。

「数千数万のクライアントからのコネクションを維持したままだとサーバのメモリを食って死んでしまう」→「ならば、そんなクライアントとは手を切るぜ」→「そのためには..」という常識がうまれた。

ELBはトラフィックが増えれば自在にリソースを変更するすぐれもの。そもそもELBがTCPのセッションを維持するのにどんだけメモリを食っていようが、そんなことはユーザの知ったことではない。そこが普通のロードバランサとは違う。

ELBをサーバとクライアントの間において、コネクションを維持したらどうなる? クライアントががんばって用意しているHTTP keepaliveはELBとの間で維持して、サーバはELBとのコネクションだけを考えればいいから、高速化する。

というわけで、ELBを使わない手はないし、その機能を生かすためにwebサーバはTCP keepaliveを有効にしてTimeoutを120秒にするのがいいのでした。

2012年6月14日木曜日

RDSは1秒未満のスロークエリを記録できない。そこでmin_examined_row_limit



いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。

そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。

漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ

min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全体の性能を劣化させる危険性があるので、long_query_timeを少し大きめにしておいて、このオプションを併用しておくといいだろう。例えばmin_examined_row_limit=10000など。いずれの変数もアプリケーションの特性に合わせて調節して欲しい。

これをRDSで一発でやるなら

$ rds-modify-db-parameter-group sweet-parameter-group --parameters "name=slow_query_log, value=ON, method=immediate" --parameters "name=long_query_time, value=1, method=immediate" --parameters "name=min_examined_row_limit, value=10000, method=immediate"

といった具合になる。

2012年6月13日水曜日

マイクロDBインスタンスのRDSのアレな活用

【AWS発表】Amazon RDS MySQL を月26ドルで! マイクロDBインスタンスが利用可能に! 

ということで、安くRDSを使うことができる。ただし、マイクロインスタンスなのでどうしようもなく遅い。耐えられないくらい正直遅い。

が、それを逆手にとった活用法がある。

それはスロークエリの検出。

2012年6月12日火曜日

Amazon CloudFrontの新機能の解説webinarをやった

Awsmeister cloudfront20120611-slideshare用 [slideshare id=13350408&w=425&h=355&sc=no]
View more presentations from yasuhiro araki

というわけで、Amazon CloudFrontの新機能の解説webinarをやった。なぜ速くなるかのツッコミとかやってられなくなるくらい機能が増えてきたなあ。。最初にやったときはRoute53とまとめてやったのにな。

2012年6月9日土曜日

750時間ぶん使える話。

ところで一ヶ月の計算のしかたは、3日間は72時間。その10倍は720時間。一日足しても+24時間で744時間と覚えましょう。

744も覚えやすい数字だよね!

2012年6月7日木曜日

MySQL Enterprise EditionとRDS

散々Amazon RDS for MySQLなるMySQLサービスを売っているのだが、それでもMySQL Enterprise Editionはすばらしい製品に見える。

違いをメモってみるか。ちなみにRDSはMySQL community edition.

  • MySQL Enterprise Backup: これはRDSはバックアップの仕組み(snapshot)もあるしポイントインタイムリカバリもあるからいいか
  • MySQL Enterprise Monitor: MySQL Query Analyzerいいなあ。RDSにないし。
  • MySQL Workbench: 管理ツールはまあRDSにはいらないのかもしれない。
  • MySQL Enterprise Security: LDAPやAD連携なんかはいいよね。RDSにもあっていいね。
  • MySQL Enterprise Scalability: スレッドプールは圧倒的だよね。。
  • MySQL Premier Support: @nippondanjiのサポートうけてみたいよね。。(#やっているかは知りません)

そんなわけで、欲しいものはまだまだあるのであった。

2012年6月6日水曜日

JAWS UG東京

本日は富士ソフトさんにどうしてもはいりたい理由があった。そして立ち見が不可能ということでなんとか仕事をすることで会場にはいることにした。そして選んだのはtweet係。

つぶやき仕事の前は受付もしていた。で、本番のtweet(togetter).
それにしても、何度聞いても大石さんのプレゼンは涙が出る。この赤十字の事例のプレゼンは感動的すぎるので、ぜひラスベガスでも話をしてほしい。

2012年6月5日火曜日

AWSデータベースサービスxソーシャルゲーム祭り

正直な感想を言うと、「祭り」な印象はなかった。

「逐次通訳がはいると頭が覚めてしまう」という仮説をたてた同僚もいたが、その場で否定になった気がする。

レポートはサーバーワークスのblogをみるのがいいかな。

2012年6月3日日曜日

家から40分くらいのポタリング

AWSのサービスがあると唯一公言しているEquinix TY2。家からチャリでも行けるところなのはわかっていたので行ってみた。

家->大橋JCTのとこから目黒川->現地 というかんじなのだが、中目黒駅のあたり、目黒区のスポーツセンター? のあたりの異臭というかドブ臭さはやばいな。

2012年5月31日木曜日

AWSのコマンド類と環境変数

Installing AWS Command Line Tools Using Ubuntu Packages というすばらしい記事が http://bit.ly/JTpa8f で読めるのでそれのインスパイアというか、ちょっと修正しただけ。

まずはAmazon EC2 API Toolsをいれる。Ubuntuな場合は上であげた http://bit.ly/JTpa8f あたりを読めばいいけど、なるべく汎用的に書いてみる。

  1. まずはJDKのインストール.
  2. 適当なdirectoryをつくる。UNIX系なら、~/.aws おすすめ。
  3. ec2-api-toolsやautoscaling、ELBのコマンドファイルなどは http://aws.amazon.com/code にあるので、とってきて展開して、シンボリックリンクをつくる。まあ、やたら種類があるので全部いれる人は極めて稀だと思う。自分だとこんな具合
    ~/.aws$ ls
    AutoScaling/
    AutoScaling-1.0.9.0/
    ElasticLoadBalancing/
    ElasticLoadBalancing-1.0.10.0/
    RDSCli@
    RDSCli-1.4.007/
    bin@
    ec2-api-tools@
    ec2-api-tools-1.5.0.0/
    lib@

    リンクについては

    ec2-api-tools@ -> ec2-api-tools-1.5.0.0
    bin@ -> ec2-api-tools/bin/
    lib@ -> ec2-api-tools/lib/

    といった具合。

  4. credential情報のはいったファイルを作成。なんでもいいんだけど、https://aws-portal.amazon.com/gp/aws/securityCredentials からコピーしたものを.aws/aws-credential-file あたりにつくっておく
    $ more .aws/aws-credential-file
    AWSAccessKeyId=xxxxxxxxxxxxxx
    ASWSecretKey=yyyyyyyyyyyyy
  5. 次は環境変数の整備
    export AWS_HOME=$HOME/.aws
    export EC2_HOME=$HOME/.aws
    export EC2_PRIVATE_KEY=$AWS_HOME/pk.pem
    export EC2_CERT=$AWS_HOME/cert.pem
    export EC2_URL=http://ec2.ap-northeast-1.amazonaws.com
    export JAVA_HOME=`/usr/libexec/java_home`
    export AWS_CREDENTIAL_FILE="$EC2_HOME/aws-credential-file"
    export AWS_AUTO_SCALING_HOME="$EC2_HOME/AutoScaling"
    export PATH=$AWS_AUTO_SCALING_HOME/bin:$PATH
    export AWS_ELB_HOME="$EC2_HOME/ElasticLoadBalancing"
    export PATH=$AWS_ELB_HOME/bin:$PATH
    export PATH=$EC2_HOME/ec2-api-tools/bin:$PATH

2012年5月28日月曜日

DevOps Day Tokyo 2012に参加してきた(昨日の話)ので報告と雑感。

昨日DevOps Day (sじゃない)のイベントがセルリアンタワーのGMOであったので参加してきた。

今回は正直誰が何をしゃべるのかもわからなかったので速攻で申しこみだけをしておいた。そうしたら、opscodeもenTRUSTもいるという俺得なイベントでした。積極的に質問もしたら、いろいろ出てきたのがサイコーだった。そんなわけで、いろんな話もできたし、最後に一本締めのときに前に出ることにもなったり、とても楽しい一日でした。講演者の方々、主催、スポンサー、会場のGMOの方々ありがとうございました。

全体の雰囲気は、http://togetter.com/li/310514、隣で取材してた新野さんのpublickeyに出る気がするのでそちらを参照。

以下は自分が体験したこと。

まず、opscodeのGeorge Moberlyさんから、

次のchefバージョンではDry Runがサポートされる

という言葉をもらったことはかなり心強い一言だった。他にもchefに関しては、日本でのトレーニングやCertification programの話を聞いてみたところ、前向きに考えているとのことだった。

次に、DevOps Cafeの主催のJohnとDamonにも彼らの発表に質問したり、発表がおわってから後ろで何か話をしているところにはいって話ができた。技術から金の話までおもいっきり楽しめた(enSTRATUSのビジネス配分についての話まではしなかった)。もちろんAWSで仕事してることは隠さなかったので、そこで丁度いいと思われたのか、彼らのPodCast用の取材を受けることになった。木曜か金曜あたりに私のビデオが彼らのwebから、podcastは音声だけなので私のやばい英語が世間に出ることになるはず。

今回意外だったのは、Private vs Publicのセッションでも主張したのだが、意外とみなさん教育(新人教育や、外注、パートナー育成など)の悩みがないようだ。chefに関して「日本語化しなくてもいいよ」という話がでた。私は日本語じゃないと。。という声や、サービスやツールがサステイナブルに使われるには教育がないと、という声を日々聞いているが、こういう会にきて実際に触ってる人からすると考えることではないのかもしれない。

2012年5月27日日曜日

VPCにタグつけれるんだが


$ ec2-describe-vpcs
VPC vpc-95aa06fc available 10.0.0.0/16 dopt-69ab0700 default

となっていたもの。

こいつに"hoge=vpc1000"という名前をつける


$ ec2addtag vpc-95aa06fc --tag hoge=vpc1000
TAG vpc vpc-95aa06fc hoge vpc1000

すると、


$ ec2-describe-vpcs
VPC vpc-95aa06fc available 10.0.0.0/16 dopt-69ab0700 default
TAG vpc vpc-95aa06fc hoge vpc1000

まあ、tagはつけられると。

まあ肝心なことはここを読めと。
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/Using_Tags.html

2012年5月24日木曜日

ELBの扱えるTCP portは25,80, 443 or 1024 to 65535

これもまた知られてないシリーズか。
ELBの扱えるTCP portは25,80, 443 or 1024 to 65535。
そして、違うportにアクセスしてもICMPでrefuseを通知したりはしない。

2012年5月22日火曜日

easyRoute53: Route53を前提のドメインレジストラ

easyRoute53: A GUI, User Interface to Amazon's Route53 DNS with Registrar Support

まあ中身的には大したことをしているわけではなさそうではあるが、GUIがほしい人、楽したい人はあってもいい選択肢だと思う。

easyDNS and Amazon are not partners or affiliates.

としっかり断り書きもはいっているのも好感か。

どんなことをしているのかは、スクリーンショットをみるのがいいね。

2012年5月21日月曜日

wowzaはけっこう使われている話。

AWSの英語のフォーラムをながめてたら、南米のオンプレミスでエンコしたものを日本から配信したい話っぽい。

AWS Developer Forums: When the DirectConnect will be ...

We are planning media streaming service from South America to Asia-Pacific. The streamer in AP EC2 instance will keep pulling live feed video from SA.
1) So, we have to be guaranteed on network bandwidth from SA to AP. Your DirectConnect service seems to be not available yet. when will it be?
2) without DirectConnect, It there any other AWS service that will enhance the network bandwidth usage for media streaming from region to region? TIA

wowza mediaは http://www.wowza.com/pricing/ec2-streaming に詳細がでているが、wowzaからライセンスを買って持ちこむことも、AWSからpaid amiという形でEC2の利用料金に上乗せするかたちでも使うことができる。

比較対象としてはAdobeのFMSとMS IISストリーミングなんかがあるのだが、Wowza,AdobeFMS, IISの比較表がでている。なんといってもFlash,silverlight,quicktimeと扱えるフォーマットの広さと安さ、そして配信パフォーマンスが魅力的。

もちろん東京リージョンでも使える。

Amazon VPCのネットワークにまつわる細かな話

これへの答えとしては、

各サブネットにおいて、Amazon が先頭の4 IP アドレスを確保し、最後の1 IP アドレスは、IP ネットワーキングの目的で確保されます。 http://aws.amazon.com/jp/vpc/faqs/#I8

ので、典型的には

ということになる。

他の細かな話。

(@shot6 による情報を得て修正)

    2012年5月20日日曜日

    NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較 など。

    NHNテクノロジーカンファレンスにいってきた。

    DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。

    "Mobage DBA Fight against Big Data" - NHN TE [slideshare id=12990643&w=425&h=355]
    View more presentations from riywo

    実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。

    このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。

    サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。

    RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなインスタンスに設定を変更する。詳細はFAQの#20を参照

    「バックアップ」サーバ。マスタおちたときのレプリ昇格用。デイリーのバックアップ用。サービスからは参照されていないただのスレーブ。デイリーバックアップは人のすくない朝3時とかにmysqldump

    RDSの場合は、http://aws.amazon.com/jp/rds/faqs/#23 にあるように、デイリーの自動化バックアップと、任意のタイミングでのデータベース スナップショットを提供している。

    MHAでは、データの整合性をたもち、スプリットブレインがおこらないように、マスタ切り替え。IPのきりかえまでもやってくれる。夜中におちても切り替え時間だけの停止。計画的に使うこともできる。

    RDSであれば、可用性向上のためにさらにMulti-AZオプションが使える。http://aws.amazon.com/jp/rds/faqs/#36 にあるように、Amazon RDS は別の Availability Zone において同期する、「スタンバイ」レプリカを自動的に設定して管理します。DBインスタンスに対する更新は、複数の Availability Zone 全体において、スタンバイに対して同時にレプリケーションされます。

    フェイルオーバー時、Amazon RDS は単純に DB インスタンスの正規名レコード(CNAME)を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。DBサイズにもよりますが、3分以内で復旧します。

    ここまでいいことを書いたけど、RDSでは絶対にできないことは、お客様側のアプリで対応しないといけないこと。そしてInnodb以外を使うこと。というわけで、次の2つはさすがのDeNAの総合力といったところだろうか。

    UPDATEの最近の命題。ロックをどれだけ短かくするか。ソシャゲは綺麗なもんばかりじゃないのでデッドロックはおこる。そこでロックの順番をアプリで管理させる(理想) or バージョンをつかって楽観ロック 

    プライマリキーでのSELECTの機会は多い。そこでHandler socketの登場。SQLパーサをはぶけるので速くなる解説。

     

    2012年5月19日土曜日

    AWSで一番でかいIPブロックはどこか

    AWSではいくつか使用しているIPブロックを公開している。

    けっきょくのところ /14 より大きなブロックは存在しないことがわかる。そして、そんなでかいのがあるのはUS東海岸だけということ。。

    2012年5月17日木曜日

    AmazonLinuxにfluentdをいれてみる

    fluentdの特集記事がのっているというSDが明日発売。

    よく考えたらAmazonLinuxでさわったことがなかったので、インストール最小手をさがしてみようということで。

    sudo yum install ruby19 ruby19-devel
    sudo yum remove ruby
    sudo gem1.9 install fluentd

    (略)

    Successfully installed msgpack-0.4.7
    Successfully installed json-1.7.3
    Successfully installed yajl-ruby-1.1.0
    Successfully installed iobuffer-1.1.2
    Successfully installed cool.io-1.1.0
    Successfully installed http_parser.rb-0.5.3
    Successfully installed fluentd-0.10.22
    7 gems installed
    ERROR: While executing gem ... (Gem::DocumentError)
    ERROR: RDoc documentation generator not installed: cannot load such file -- rdoc/rdoc

    最後にrdoc由来のエラーがでるが、ドキュメントはサーバ側にいらんのでこれでよいことに。気持わるいなら、--no-ri --no-rdoc をつければokなはず。

    一応

    fluentd --setup ./fluent
    fluentd -c ./fluent/fluent.conf -vv &
    echo '{"json":"message"}' | fluent-cat debug.test

    で動作も確認。

    NATインスタンスのパフォーマンスが心配な方へ。

    VPCではプライベートIPアドレスだけで構成されているために、Publictなthe Internetに出ていけないインスタンスを置くことができる。

    このようなインスタンスでも、NATインスタンスを使うことで、インターネットに出ていくようにすることができる。

    途中まで書いて気がついた。↑の記事がすばらしすぎることに。みんなこれを見るべき。

    たまにNATインスタンスのパフォーマンスを気にする人がいるので、そのヒントを。

    • NATインスタンスはいくつでも作れるので、負荷分散
    • NATインスタンスを速いインスタンス(c1.xlargeとか)にすることも有効
    • Squidの透過proxyなどつかうと劇的に効果が出るときもある

    といった具合。

      2012年5月16日水曜日

      CloudFrontで使っているCA証明書について

      たまに聞かれるCloudFrontの証明書について。

      どんなものがはいってるかについては、Firefoxでも使えばすぐに調べがつく。

      というわけで、http://www.entrust.net/developer/index.cfm がCloudFrontで使用している証明書。

      SSL事業者からの情報

      在野の情報

      2012年5月15日火曜日

      今日からサポートされたCloudFrontの動的URLサポートのこまかい話

      CloudFrontがかなりパワフルになった。おねだんはそのままで!

      どれだけかわったかと言えば、とりあえず前のことは忘れてもいい(覚えていたほうがもっといいが必須ではない)と思えてしまうほど。(大枠は、【AWS発表】Amazon CloudFrontが動的コンテンツをサポート あたりを読んでいただきたい)

      これが今日からのwebサイトの標準体だろう。



      さて、ありがたいことに、動的URLといえばQuery Stringということで、すかさず質問をいただいたので。。



      というようなことを書いた。ついでなので細かなことを書いておこう。

      Query Stringについて

      • Query Stringはオプション機能として提供。有効にすると、Query Stringもすべて含んだfull URLがオリジンに送られる。
        • ロギング機能を有効にしていれば、Query Stringは記録される。
      • Query Stringの順番、大文字小文字に注意
      • Private Content機能を使うときにCloudFrontで予約しているQueryがあることに注意。
        • Expires, Policy, Signature, and Key-Pair-Id are reserved query parameters
      複数のオリジンサーバのサポートについて
      • S3 bucket, an ELB, an EC2 instance, a custom originなどなどを指定できる
      • 10オリジンまで. それぞれ”Origin ID”が付与される

      2012年5月7日月曜日

      EC2を便利につかう.ssh/configの書きかた


      というわけで実はあまり知られてない方法なのかもしれないので、具体例を晒しとく。
      Host *.ap-northeast-1.compute.amazonaws.com
      identityfile ~/.ssh/tokyo
      user ec2-user
      Host *.eu-west-1.compute.amazonaws.com
      identityfile ~/.ssh/dublin
      user ec2-user
      Host *.sa-east-1.compute.amazonaws.com
      identityfile ~/.ssh/saopaulo
      user ec2-user
      Host *.compute-1.amazonaws.com
      identityfile ~/.ssh/virginia
      user ec2-user
      Host *.us-west-1.compute.amazonaws.com
      identityfile ~/.ssh/california
      user ec2-user
      Host *.us-west-2.compute.amazonaws.com
      identityfile ~/.ssh/oregon
      user ec2-user
      Host *.ap-southeast-1.compute.amazonaws.com
      identityfile ~/.ssh/singapore
      user ec2-user

      2012年5月5日土曜日

      Amazon Linuxでmosh

      moshがはやっていて、最近いいかんじにつかっているのだが、AmazonLinuxでつかってなかったので試した。

      yumで一発にはなってないのでちまちまとコンパイル.

      まず下準備

      $ sudo yum -y --enablerepo=epel install boost-devel zlib-devel ncurses-devel protobuf-devel autoconf automake gcc gcc-c++

      お次はgitからソースをもってくる。

      $ git clone https://github.com/keithw/mosh

      コンパイルとインストール

      $ cd mosh
      $ ./autogen.sh
      $ ./configure
      $ make
      $ sudo make install

      すると、

      /usr/local/bin
      /usr/local/bin/mosh-server
      /usr/local/bin/mosh-client
      /usr/local/bin/mosh

      あたりができてる。

      security groupにmoshをつくって60000-61000のudpを開放する。その後で、つないでみる。

      mosh --ssh="ssh -i .ssh/secretkey" ec2-user@a.b.c.d

      2012年4月25日水曜日

      JAWS仙台でキューイングとストリーミングの話をした

      SlideShareにうpした。昨日発表した新ネタです。メディア配信をネタにキューイングのCDPを2つ使いました。 そしてファイル配信からストリームにかえるパターンに名前をつけるんだった。

      この発表のキモは

      • キューイングをつかってffmpegの利用を最適化しよう
      • 重みづけキューイングをつかうと優先会員なんかもつくれる
      • ファイル全体をdownloadさせると金ばっかりかかるダウンロード厨が避けられなくなるので、ストリームも活用しましょう

      20120425 cdp-stream [slideshare id=12701578&w=425&h=355]
      View more PowerPoint from yasuhiro araki

      それにしても仙台の復興需要はすごい。ホテルはとれなかったので急ぎでかえることになった。

      そうなれば夕飯を駅弁にしようかとおもったが、仙台なのに駅弁が全滅! この駅弁激戦駅なのに、おかししか食っとらん状態でのりこみ。。せつないねえ。

      2012年4月23日月曜日

      The 10 Biggest Mistakes Made With Amazon Web Servicesについて

      The 10 Biggest Mistakes Made With Amazon Web Servicesという記事について、こんなやりとりをした。

      ミスリードというのは言いすぎだった。「RightScale, enStratus, Scalr, Scalextremeをうまく使うのと、DevOpsを学ぶ」こと自体は大賛成。

      しかしながら、この10個のミステイクのうち、いくつかはこういう便利ツールやDevOpsの考えを導入すればokとはならない。その意味で「銀の弾丸ではない」という意味でした。

      解決できそうなものは1-9までのこれ。これらは実にもっともなこと。そしてすぐに実現できる。しかし「導入するかどうか」の判断はずっとつきまとう。

      「面倒だから」「やりかたがわからないから」という壁をおおはばに低くする意味でツールを導入する意味はある。

      • Picking oversized instances.
      • Picking oversized instances.
      • Failing to make the right trade-offs when selecting instance types.
      • Leaving instances running idle. 
      • Forgetting to clean up stale resources. 
      • Taking too few or no EBS Snapshots.
      • Taking too many EBS volume snapshots.
      • Forgetting to release allocated Elastic IPs. 
      • Failing to proper configure security groups. 

      そしてこれらのツールでむずかしいのはもしかしたら、最後の

      • Not taking advantage of multiple Availability Zones.  

      これだろうか。やはりお金もかかるし。

      2012年4月19日木曜日

      AWS summit NYC 2012に参加した。

      AWS NYC sumit ではだれも、ろくろまわしてない。どっちかというと交通整理的な手の動きが多い、そんな回でしたがざったなまとめ。

      • 基調では様々な発表があったが、Pinterestの話が一番だった。
        • pinterest: 7時が60%くらいのserver utilizationになるようにauto scale. 1時間あたり52ドルが夜7時のpeak時につかっている計算。その時間には2割はspot instance. 2割がリザーブ。のこりはOndemand
        • CyclecomputingがたんにEC2をつかっているだけでないことの発表。Shared FS、Shedularがどうなってるか気になるが、全体図がでてきた。詳細は http://blog.cyclecloud.com を見ろ。3000サーバを10分毎にChefでコントロール!
      • Cloud as a enterprise extensionのセッション
        • エンタープライズにAWS導入した人が一番やっておくべきだったことはソリューションアーキテクトへの早期の相談らしい。
        • DR手順の書き出し、Backup、失敗プラン想定、Windowsの機能が動かないことへの回避策、いずれも重要だが、それすらも相談が早期にあればできたことだったという。
      • RDSのセッション
        • いつもの "YesSQL"と"NoSQL"の話はヤヤウケだった
        • DBをつかうアプリにおいて、コードをかく時間は5%。チューニングは20%。これは過去のものにしよう

      一日おわってえらい人につれられて肉に。うまかったけど4時間半はながすぎた。。

      2012年4月14日土曜日

      CDPナイト!

      こくちーずで募集したCDPナイト.

      CDP概要 by AWS玉川(@KenTamagawa)

      CDP実装シナリオ

      ・画像・動画配信編(Movable Type) by 片山(@c9katayama)

      ・Eコマース編(EC-CUBE) by 玉川(@KenTamagawa)

      ・キャンペーンサイト編(Wordpress) by cloudpack 鈴木(@suz_lab)

      ・VPC移行編   by 荒木(@ar1)

      ・バッチ処理編 by 大谷(@shot6)

       

      新パターン提案LT

      ・cloudpack 後藤(@kaz_goto)

      ・Serverworks 柳瀬(@oko_chang)

      ・マイニングブラウニー 得上(@tottokug)

      というわけでVPC以降編を発表した。

      議論があまり出なかったのが残念。完全に新コンテンツじゃないともりあがらないのかなあ。

      AWSクラウドデザインパターン VPC移行編 [slideshare id=12136658&w=425&h=355]
      View more PowerPoint from yasuhiro araki

      2012年4月12日木曜日

      cloudpack、AWSの東京リージョンと直結する「専用接続プラン with 光」の提供 を開始

      というわけで、私がながいこと担当しているAWS DirectConnectサービスにあらたな一歩。



      フレッツでない専用線へのupgradeもあるらしい。

      すばやく使いたい、一時的にだけ使いたい、専用線までのつなぎに使いたい、拠点が遠い、などのユーザにとっては朗報なんじゃないかと思う。

      そうそう。SaaSの皆様は、全部自分でやろうと思わずに、cloudpackさんのようなところと組むとよいと思います!

      2012年4月5日木曜日

      RAIDとかやめてS3でいいよ

      まあ、S3「で」いいのではなく、S3「が」いいのです。

      S3のいいところをあげていくとキリがないのだが、こういう話をすると

      xxx はS3互換です

      のように言われる方がかなり多い。これは一種のFUDのようなものなのだが、それぞれそれなりに意味があるらしい。私が調べたところによると、だいたいこんな理由で「S3互換です」と言っているらしい。

      • Amazon S3を作っていた人が作った会社の製品です
      • RAID6を3筐体でやっています
      • S3に対応したxxxクライアント (他にもいろいろといれていい)がサポートしています
      • オブジェクトストレージです
      • REST対応です

      ともかく、いろいろある。なんでこんなことを書いているのかといえば。



      なるものを見たので、

      10:39 RAIDとかやめてS3でいいよ

      と書いたら、まさかの @jasobrown (Netflixのチーフアーキテクト)からmentionされたからでした。

      16:58 RT @jasobrown_jp: @ar1 NetflixのデータはぜんぶS3につくてる。

      2012年3月25日日曜日

      Route53のlatency based routingの利用

      Multi-Region Latency Based Routing (http://goo.gl/wkkra ) という機能がAWSのDNSサービスであるRoute53から発表されました。


      そもそも、cdn.debian.netの全体図はこんな具合。cdn.debian.netの再実装開始という記事



      dns_balanceが動作しているホスト(当然DNSサーバが動いている)に対して、どうやって早く接続するのか、という問題がある。


      今回発表された、Multi-Region Latency Based Routing で、日米欧で動作させているdns_balanceに対してエンドユーザ(の使っているDNSキャッシュサーバ)を誘導するようになりました。


      これまでは、日本のユーザでも一定の割合でヨーロッパのDNSサーバを参照する場合があった(キャッシュサーバの実装次第)のが、なくなり、300から500msecほど(平均ではその1/3)解決までの時間が短かくなったはずです。

      2012年3月24日土曜日

      cloudpack night 2でVPCのシナリオ発表

      本日はcloudpack(iret)さんにおじゃましてのcloudpack night #2でした。

      そこで発表した。VPCで使えるパターンとして残っているものはまだあるけれど、今回は

      • cloudformer + cloudformation
      • Elastic Network Interface
      • Security group
      • Network Access Control List
      • Route53

      このあたりの使い方シナリオの発表という具合。発表の中にもありますが、PCI-DSSのProvider Level1をAWSは取得していますが、それにはVPCが大前提なのです。

      AWSクラウドデザインパターン VPC移行編 [slideshare id=12136658&w=425&h=355]
      View more PowerPoint from yasuhiro araki

      2012年3月19日月曜日

      AWSゲームテンプレートという名のCloudFormation公開

      一昨日、OGCというイベントがあり、外苑前のTEPIAでイベントをやった。最近はwebsocketで常時接続アプリというのがわりとはやっていて、AWSでのやりかたをひとつ見せてみようということでcloudformationのテンプレートにしてみた。

      公開は、http://ogc-template.s3-website-ap-northeast-1.amazonaws.com/ で行っている。詳細はそちらへ。

      2012年3月3日土曜日

      Elastic Load Balancerをつかってwebsocketを処理する方法

      AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。

      最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、
      ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。

      そもそも問題は、

      1. ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。

      2. ELBでTCPモードにした場合でも60秒でタイムアウトする。


      の2点が原因です。そのため、2つの方法があります。

      解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法
      C ---------> ELB(HTTPモード) --> S   ふつうにHTTPでアクセス。
      C <--------- ELB <---- S スクリプトがダウンロードされる

      このスクリプトには Sのアドレスpublic ホスト名がそのまま埋めてある
      C -------------------> S websocketで接続
      C <--------------------S websocketのネゴ

      という具合でELBは最初にだけかかわります。

      解2: websocketでping/pongを行う

      クライアントをいじるのはむずかしいでしょうから、サーバ側からPINGを60秒に一度
      はなげることになります。
      C ---------> ELB(TCPモード) --> S   ふつうにHTTPでアクセス。
      C <--------- ELB <---- S スクリプトがダウンロードされる
      C ----------> ELB ------> S websocketで接続
      C <---------- ELB <----------S

      websocketのpingを以降、たとえば30秒に一度なげます。

      2012年3月2日金曜日

      明日のAWSマイスターリターンズで聞きたいことを事前募集!

      http://jaws-ug.jp/summit2012/ で御案内していますが、

      AWSマイスターリターンズ

      ほぼ週刊で開催しているAWSの主要各サービスを説明する「AWSマイスターシリーズ」の内容を、濃縮還元バージョンでお届けするセッション。1セッション25分の構成で、ほぼすべてのサービスをカバーします。これまで知らなかったサービスについても、まとめてキャッチアップできる絶好の機会です。


      というところで登壇して25分x3ほど、VPC, CloudFront, Route53、Storage GatewayについてDiveします! インタラクティブなやりとりをしたいのですが、会場で質問するのはなあ。。という方、時間をとりそうな質問があるんだけど、、という方、ぜひ事前に意見をおよせください!

      https://docs.google.com/spreadsheet/viewform?formkey=dGtxY1U0dTlkb0t5WnlUbF9iVHJnN2c6MQ ←こちらからどうぞ

      [googleapps domain="docs" dir="spreadsheet/embeddedform" query="formkey=dGtxY1U0dTlkb0t5WnlUbF9iVHJnN2c6MQ" width="760" height="957" /]

      DynamoDBが東京リージョンで利用可能になった

      ついにきた、もう来たというポジティブな反応を様々な方にいただき嬉しい限り。オフィシャルblog をみればだいたいのことはわかるのでまずそれを見るとして。

      このDynamoDBをちゃらっと試すのにJavaを使っていたのだが、rubyでそういや使ってなかったことに気がついたので調べてみた。

      DynamoDBはクエリを前提にしているようなコード書きとはかけはなれすぎているので、SQL路線できた方が、実際使う方はあんまりいないかなあ、と個人的には思っている。

      セッション情報をDynamoDBにつっこむようなミドルウェアがはやらないとね。memcacheでやる人は沢山いるので、そのへんのライブラリを書きかえればいいのか。。

      2012年2月19日日曜日

      Jaws大阪のみなさん、Skypeでこんにちは

      Jaws大阪が18日に開催された。シアトルでは金曜の夜だったのでディナーを抜けだして1時間前から準備をして待機。

      いろいろと準備に協力いただいた大阪コアメンバに感謝。

      玉川+SAが話をした。自分はVPCを強くアピールしたつもりだったけどどうだったかな。その話がおわったあとで、乾杯を中継した。きっとあれでいいのだろう。後悔はしていない。

      この写真は中継前の様子。これがおわったあとで皆でJAWS大阪のUSTを見て、さらにそのあとで戦略会議をしていた。

      2012年2月16日木曜日

      AWSはLittle Big Planetでも使われています

      Little Big Planetの事例. http://bit.ly/yv8oDt AWS(EC2, S3, SQS, CloudFront) + Varnish + Nginx + Ruby + HAproxy + C++

      これは一部の人にはとても興味深いもの。なにしろ、varnish+Nginx+Rubyだからね。。

      たしかにX-Varnishがつきまくっている。

      2012年2月12日日曜日

      Linux Distributionカフェというネタ

      https://twitter.com/#!/ar1/statuses/167752922602536960
      Gentooカフェ→材料が出てきて自分で作る Debianカフェ→依存関係で色々パックが追加されていく RHELカフェ→会員制で入会費が高い CentOSカフェ→色々な所に別メニューが散らばってる Ubuntuカフェ→頻繁に改装する
      これはおもしろい。どれも使ったことがあるのでよくわかる。

      さて、ではAmazonカフェはどんなふうになるか。AmazonLinux を知らないひとは知ってもらうとして、基本的にはRHELバイナリ互換のLinuxでサーバ用途に特化している。そしてEPELが使えたりするからCentOSっぽいともいえる。そういう意味ではめだった特性がない。その特性の他とあきらかに違うところは、AWSの中でしか使えないところだろう。

      さて、そんなわけでカフェとして考えるならなんだろう。
      Amazonカフェ→材料が豊富にある市場に併設された場所で自炊する。使った材料と居た時間でお金がきまる。

      2012年2月8日水曜日

      なれる!SA(ソリューションアーキテクト)

      今日こんなことを書いた。
      すでに日本のAWSはでかくなっているので私と同じSAやセールスは日本語だけでレジュメ、面接とも突破できる道ができているのだ。

      正直言うと、自分がAWSのSAになるために面接を受けまくっていたときは、@hide69oz と @kentamagawa との面接以外は英語だった。それもビデオ面接のはずが壊れてて電話面接になったり、英語でも日本語でもいいけどどうする? と言われて英語を選んだり、むずかしいほうに自分で倒したこともあったのでもうすこし楽はその当時からできたとはいえ、英語が必須だった。そして聞くところによると最後まで「荒木の英語は大丈夫か?」とは思われていたらしい。
      そのときからすると今は全然違う。テクニカルセールス、SAはたぶん英語なしで採用プロセスは通せる。レジュメにも英語はいらない。

      そんなわけで、AWSでのSAを考えている皆様、いきなり私にレジュメをよこしていただいてもかまいませんし、もっと情報欲しいということであれば、よろこんでお話します。
      まずは面接を楽しんでいただきたい。はいったら、たのしい仕事であふれていることは保証します。
      あ、なれる! SEみたいな女性は今はいません。。

      2012年2月4日土曜日

      東北デベロッパーズカンファレンス4thでプレゼン

      例によって色々な人におせわになった東北デベロッパーズカンファレンス4thでプレゼンしてきました。

      • 丸山先生によるこの10年のITの流れのまとめ。
      • Googleの及川さん、北村さんによるHTML5でどんどんnativeアプリに近づいてるはなし。
      • MS春日井さんによるHTML5の事例どーん
      • 自分のプレゼン
      • DDDのおはなし @digitalsoul0124 さん。

      という流れだった。そのあとでLT大会ありの懇親会。

       

      インフラ系自主トレするならAWS [slideshare id=11413400&w=425&h=355]
      View more PowerPoint from yasuhiro araki



      http://tohoku-dev.jp/modules/forum/viewtopic.php?topic_id=40&viewmode=flat に全体のまとめあり。

      http://togetter.com/li/252408 が全体の流れを追うには便利。

      2012年2月3日金曜日

      WebsocketをELBで使うならTCPモードで。

      websocketがにわかなブームから、力強い動きへと変化してきているように思う。

      正直websocketを活用する人はよく分かっている人が多いので、具体的に質問を受けたことはないが、AWSのロードバランササービスであるELBを使ってwebsocketを負荷分散する場合には今のところHTTPモードではなく、TCPモードで使わなければならない。

      ひとことでいえば、websocketはwebsocketであってHTTPではないから。HTTPでネゴシエーションをはじめるが、それが終わったらwebsocketに移行する。

      とまあ、ここまで書いてておもったけど、protocolとしてのwebsocket、APIとしてwebsocket、実装としてのwebsocketなどなど人によって言っていることが違うことが多いので、自分も含めて人と話をはじめるときにもネゴが必要だなーと思ったのでした。

      2012年2月2日木曜日

      私は本来あまり出張しない仕事ですが今月はちょっと出ます

      本日ある人と長々と話をした。

      私と同じポジション(SA)のイケメン@shot6 が1ヶ月遅れで入社してきて、今日で丁度1年。おめでとうありがとうございます!

      それから半年は2人で仕事を適当にわけて仕事をしてきた。気がつけばだいぶ人数も増えてきた。そしてなんとなく仕事の分類もできてきた。

      自分の担当する仕事は東京のお客様が多い(そもそも東京だったり、東京に支店があったり)ので東京の中をうろうろしていてめったに都外に行くことはない。4月なんかは80社くらいいってるのに全て山手線の内側かつ、総武線の南側だったりしていた。

      それにひきかえ、新幹線に毎週8時間くらい乗る人もいたり、ほんとうにまちまちだ。そんな仕事をしているのに、今月は2つ遠い出張がある。

      実にめずらしい。

      エヴァンジェリストと名がつくと、後藤さんはこんなことをしている (http://www.cloudpack.jp/campaign/201201/ )し、wikipedia …著名なエバンジェリスト にこんなかんじで出てしまうような

      日本のIT業界における著名なエバンジェリストとしては、Amazon Web Services の玉川憲、マイクロソフトの西脇資哲、日本IBMの米持幸寿などが挙げられる。
      http://goo.gl/JDJBi

      こういう人はどうなっているのだろうか。@kentamagawaの場合は感覚的には7割出張してる気がする。

      2012年2月1日水曜日

      VPC対応ルータにAstaroが増えてる

      AstaroというかsophosがVPC対応ルータとして設定がdownloadできるようになった。

      ちょっとためしてはみたいのだが、ヤフオクに出るようなもんではないらしい。

      http://nextit.jp/ の案内を見ると評価機もあるし、virtual applianceもあるようだな。。

      2012年1月12日木曜日

      AWS-Auditというpythonプログラム(GPLv3)

      https://github.com/newsinternational/AWS-Audit

      AWS Audit README

      AWS Audit is intended to be used to both track Amazon Webservices configuration changes across multiple accounts, and also provide a data building block to be used as a foundation for other applications.

      2012年1月1日日曜日

      EC2南米(ブラジル)リージョン用のDebian AMIを作成した

      特に誰からも作ってくれとは言われてないのだが、南米リージョン用にDebian squeezeのAMIを作成した。例えば、EBS backedの64bit環境でブートできるようになった。



      他のリージョン用にも、Debianでは半ばオフィシャルのAMIを公開している。詳細は、http://wiki.debian.org/Cloud/AmazonEC2Image で確認できる。

      RightScaleのものは違うが、tomと私の作ったAMIは完全にクリーンなので安心して使ってOK。

















































      archversionAMI IDdisksizemaintainerlogin user
      32bitsqueezeami-a627f8bbinstance10GBar@debian.orgroot
      32bitsqueezeami-d427f8c9EBS10GBar@debian.orgroot
      64bitsqueezeami-0626f91binstance10GBar@debian.orgroot
      64bitsqueezeami-3826f925EBS10GBar@debian.orgroot