Infrastructure as Code Casual 札幌 #0を開催しました。 #infracode_sap
はじめに
題の通り、やりました。 infracode-sapporo.connpass.com
満員御礼、出席率ほぼ１００％で、とても盛り上がりました。
参加していただいた皆様、ありがとうございました！
その雰囲気はこちらからどうぞ。 togetter.com
一年くらい、やるやる詐欺してたのが、やっと重い腰が上がった形になります。
まあ、雰囲気や個々の発表なんかはTogetterやら、他の方のブログなんかを見てもらうとして、振り返りをしておこうと思います。
成り立ち
まあ、これにもなんとなく書いてるんですけど。
www.slideshare.net兎にも角にも、身の回りにInfra as Codeを実践してる人が少ない。北海道で真面目にやってるは自分だけなんじゃないかと思ってしまうほどに少ない。なので、話し相手が居ないのである。
話し相手を見つけたい、増やしたい。それもやってて楽しい形で。
ということで、前々から札幌にCasual文化を持ち込みたかったというのもあり、ああいった形になった。
あとはやっぱり、一人でやると辛いので身近に一緒にやってくれる人がいたことが大きい。
何故発表を「推奨」としたのか、クオリティを問わないのか
これまでの経験上（それほど多くはないものの）、勉強会的なものを楽しくて実りあるものとするために必要なものは「多様性」であると思う。色んなバックグラウンドを持つ人が、色んな話をすることで、色んな刺激が生まれる。それによって様々な意見や議論が飛び交って、盛り上がる。
また、完成された話ではなく「これからどんなことをしたいか」や「どんな話が聞きたいか」等も可とした。これには２つの目的がある。
- 実践に繋げる
分からないことや聞きたいことを聞ける場所があるというのは、実践する上でとても助けになるのではないかと思っている。自分自身、誰にも聞ける人が居ないというのは中々に辛いものがあった。
必ずしも、予め内容が決められた勉強会なんかでは聞きたいことが聞けるとは限らない。だから、聞きたいことがあるなら言ってほしい、それも大声で。そうすれば、きっと誰かが返してくれるはず。
そして、そうやって誰かに返してもらった人はきっと、次は発信する立場になってくれるんじゃないかと思う。そうやって、喋りたい人ばっかりが集まるようになるときっと、もっと楽しいはずだと思うし、自然とレベルも上がると思う。 - 議論の喚起
ある程度見込んだことであったものの、今回は本当にこれを実感した。お酒の勢いもあってとても良い雰囲気で様々なやり取りが行われ、それによって大いに盛り上がった感がある。
要は、同じ興味を持った人が集まって、好きなようにワイワイ楽しくやりながらも、実りある形にするにはこういう形も良いのではないか。と思ったという感じである。
最後に
とにかく、楽しかった。今回のは厳密には勉強会ではないけど、そういったものでこんなに楽しかったのは凄い久しぶりだったと思う。またやってくれというありがたいお言葉もいただいているし、自分自身もまたやりたいと思っているので、たぶんまたやります。
某氏は毎月とか言っていたけど、最近ちょっと忙しくなってきたし、2,3ヶ月後くらいかな。それこそ、次もまた @hokkai7go が帰ってくるタイミングでも良いかもしれない。
今回はかなり強引に開催まで持っていったので、事前の調整不足で色々と配慮しないといけない所が出てきてしまっているので、それ次第という感じもする。
とりあえず、参加していただいた皆様、ありがとうございました！またよろしくお願いします！
特定のAMIイメージの最新情報を簡単に取得できるGemを作りました
背景
まず、この辺の記事がネットで流れてきました。
「へー、便利だなー」と思った反面、以下の様なことを感じました。
「こんな複雑なシェル覚えられる気がしない」
「これ、分かったとしてその後どうするの？コピペ？」
ということで、より使いやすくプログラマブルな形で取れると良いかなと思い作ってみました。
やってることは至極単純なので、昼休み中に何とか終わったｗ
amino | RubyGems.org | your community gem host
使い方
$ gem install amino
$ pry
[1] pry(main)> require 'amino'
=> true
[2] pry(main)> Amino('name' => 'amzn-ami-hvm-*-gp2', 'virtualization-type' => 'hvm').last.image_id
=> "ami-1ecae776"
簡単ですね :-)
この例では、リージョンはus-east-1になってます。
リージョンや認証情報はaws-sdkを使っているので、同じ方法で変更できます。
第2引数に以下の様にHashで渡すとその場で指定もできます。
Amino(
{'name' => 'amzn-ami-hvm-*-gp2', 'virtualization-type' => 'hvm'},
{'region' => 'ap-northeast-1', 'aws_key_id' => 'xxxxxxxx', 'aws_secret_key' => 'XXXXXX'}
)
たぶん、使わないと思いますがfirstも一応ありますｗ
これ、もしかして
Kumogata先生と組み合わせたらめっちゃ便利なんじゃね？
既存システムでインフラのコード化を行う意義
はじめに
大抵、インフラのコード化を始めるのって新規システムとかになると思います。
たしかに、最初からやる方が途中からやるのに比べて遥かに敷居が低く、費用対効果も高いと言えると思います。
まあ、インフラのコード化に限らず、TDDとかもそうです。
新しいことを始めるのは最初からの方がやりやすい。
これが、既存システムの場合は
- 今動いているものが壊れたらどうする？
- 既に出来上がっちゃってるものにそんなにコストかけてやる必要ない
とかいう感じで、コストやリスクと得られるメリットを天秤にかけた結果、敬遠されがちなのかなと思います。
たぶん、比較対象のメリットは以下の様なものでしょう。
- 自動化による人的コスト減
- 再現性のあるインフラによる追加開発やメンテナンスの効率と質の向上
- モチベーションアップ
でも、やったことがある人には判るかもしれませんが、実はもっと重要なメリットというか、意義があるんです。
それは何か
それは、今まで見えなかったものが見えるようになることです。
インフラをコード化していくとはどういうことなのか
特に僕が多くの場面で使っているChefだとそうなのですが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業です。
そして、見えてくるものがある
例えば以下の様なものです。
- 役割を負い過ぎているサーバ
- 役割が重複しているサーバ
- 実は無くても良くて潰しちゃってコストを下げられるサーバ
- 耐障害性に不安があるサーバ
- 依存関係が複雑で追加開発や保守作業の足を引っ張りそうなサブシステム
- サービスが停止する原因となりそうな障害
他にも細かい所では、致命的なバグや脆弱性を内包したバージョンのまま動かしてるミドルウェアとかが見つかったりすることもありますが、まあそれはコード化特有っていう話ではなく二次的なものですね。
見えてくると改善できる
今までなんとなく動いていてなんとなくそのままでいたものが、見えてくることによって改善できるようになります。
そうなると、特に今後もある程度長く続くであろうシステムであれば、十分にコード化を進める意義があると思いませんか？
新規システムでもそうです。はじめからちゃんとやっておくと、全体を俯瞰して把握しやすくなり、改善計画を立てやすくし、成長スピードを速められます。
そのために
上述しましたが、そのシステムを構成しているコンポーネントを洗い出し、分類し、依存関係を整理して、コードという形で定義していくという作業をちゃんとやる必要があります。
これは、ある程度の「設計」や「実装」のノウハウが必要になります。
YAPCではその辺りをお話してみたいなと思っているので、気になる方は是非SNSなどでシェアして応援お願い致します！
以上、ステマですいません。。。
Google Spreadsheet Add-on「AWS Priceing Helper」を新しいリザーブド購入オプションに対応させました #jawsug
もっと早くやれよ、今更かよ、って話なんですが。。。
AWS Priceing Helper #とは
Google SpreadsheetにAWSの料金見積もりをするために、料金を勝手に埋めてくれる便利なカスタム関数群を追加するアドオンです。
詳しくは、今更見られるとちょっと恥ずかしい昔書いたブログをば。
blog.memolib.com
追加した関数群
- EC2_LINUX_RI_NO_AD
- EC2_LINUX_RI_PART_AD
- EC2_LINUX_RI_ALL_AD
- EC2_WINDOWS_RI_NO_AD
- EC2_WINDOWS_RI_PART_AD
- EC2_WINDOWS_RI_ALL_AD
- EC2_LINUX_RI_NO_HOUR
- EC2_LINUX_RI_PART_HOUR
- EC2_LINUX_RI_ALL_HOUR
- EC2_WINDOWS_RI_NO_HOUR
- EC2_WINDOWS_RI_PART_HOUR
- EC2_WINDOWS_RI_ALL_HOUR
関数名の意味
- 末尾
ADはAdvanced paymentで前払い金額 - 末尾
HOURはまんま時間課金の金額 NOがNo Upfrontなので前払いなしPARTがPartial Upfrontなので一部前払いALLがAll Upfrontなので全額前払いなし
ちな、時間課金の金額は公式ページには乗ってない情報だったりします。
月額が書いてあるので1年に均して割返せば分かるんですけど（っていうかアドオンでもそうやって出してる）
なぜ今更？
転職して自分で見積もりとかあんまりやらなくなっちゃったので。。。
と思ってたら、こんな感じになりまして。
けっこうな規模の見積もりレビューしてくれってSimple Monthly Calculatorのリンク送られてきて、クソ見づらいから某アレをちゃんと整備して展開すべきか…ってなってる
— Marcy Terui (@marcy_terui) 2015, 4月 14あと、Google SpreadsheetのAPI的な制限に引っかかるようになっちゃった部分とかがあっｔ（ﾓｺﾞﾓｺﾞ
ちなみに
ダウンロード数とかけっこう多い割に使ってる人ほとんどみたことないので、
最近GithubのStarとかPRくれたのも外人さんだし、海外で意外と使われてるみたいですｗ
どうぞ、ご査収ください。
IaaSのNetworkのINには課金せず、OUTにだけ課金するのは、とても理にかなった手法なんじゃないかと今更気が付きましたが何か？
とても今更感があるけど、、、「何を今更」と思ったらここで読むのをやめましょう。
ついったに書くには長くなりそうなので、落書きしてみる。
要は
INに課金しないことで、副次的に他の課金を促進できる
理由
INには多くの場合にOUTが伴う
これは言わずもがな。INがあればOUTが当然期待できる。
分かりやすいのがWebシステムで、リクエストに対してレスポンスが必ずある。
ここまでは良い。
ただ、INに対して、必ず同等のOUTがあるわけではないので、
一見するとNW帯域を消費するのはどちらも一緒で非効率なようにも感じる。
では、OUTが無い場合に起こっていることはなにか？
INがあるのにOUTが無い、あるいは出て行く量が少ない場合、内部では何が起こっているか？
内部に貯める
情報が入ってくるのに出て行かないということは、入ってきた情報を内部に貯めるということになる。
つまり、ストレージ料金が発生する。計算する
入ってくる量に対して、出て行く量または貯める量が少なくなる場合、多くのケースでそこには計算が発生する。
圧縮、分析、サマライズ、などなど。これらには必ずと言ってよいほど計算処理が必要になる。
つまり、コンピュート料金が発生する。
つまりどうなるか
INに課金しないことで「とりあえず入れとけ」的な発想を促進できる。
また、計算に料金がかかるのは当然的な意識が大半の人にはあると思うので、それなら「潤沢な計算能力を活かそう」という流れができあがる。
例えるなら
魅力的な入場無料のテーマパークで、退場時にお金が取られる。
じゃあ、せっかくだから長く遊んでいこうかってなるけど、中で生活する以上、飲食代やホテル代がかかる。そんな感じでよくできてるなあと思いました。まる。
knifeコマンドが面倒すぎるので「knife-helper」というpluginを作った #getchef_ja
経緯
コメント欄参照
knife-zeroとknife-soloとの違い
元々knife-soloを使っていた身からすると、Chef Serverの多機能さが気軽に使え、手元にサーバのインベントリがある状態で操作でき、条件で絞って一括で適用したりするのが楽なので、特に複数のサーバがある環境ではknife-soloより、とても便利です。
ただ反面、多機能ゆえにサブコマンドやオプションが多く、覚えきれないし、手数が多くて面倒な部分もあります。
これは、knife-zeroが悪いのではなく、knifeコマンド自体がそうで、knife-ec2なんかを使おうとするともっと多いですｗ
じゃあ、何があれば良いのか
initコマンド.chef/knife.rb生成BerksfileまたはCheffile生成
- ショートカットコマンドの定義
yaml等のファイルにショートカットコマンドを定義して実行できるtest-kitchen風？erbでrubyコードが埋め込めると尚可
こんな所ですかね。
ということで作った
とりあえず、ざっくり雰囲気はREADME参照ということで、詳しい使い方はこれからQiitaに書きます。書きました↓
JAWS Days 2015でAuroraの話をしてきました（あと、企業サポーターも）
題の通り、貴重な機会を貰って話してきました。
僕の本格的なAWS及びJAWSとの出会いは2年前のJAWS Daysでした。
あれから2年、今度は話す立場と企業サポーターとして参加した形になります。
当日は（特に企業サポーターの方が右も左も分からなくて）余裕がなくて実感ありませんでしたが、終わってみるとなかなか感慨深いものがありました。
発表について
まずは経緯とお礼から
事前に秋田支部の武田さんから「北海道・東北ブロックの代表として」と登壇の打診を受けました。僕が代表とか恐れ多いですが、チャンスを掴まない手はないので、当然ながら二つ返事でOKしました。この後も武田さんには色々フォローしていただき、感謝してもしきれないです。本当にありがとうございました。
その他にもAuroraのプレビューが来なくて切羽詰まっていた時に、青森の立花さんが自分のアカウントのIAMユーザの提供を打診してくれたり、同じく青森の石澤さんが東北プレイベントで僕のセッションの宣伝をしてくれたり、東北メンバーの方々がとても良くしてくれました。本当にありがとうございました。
（東北メンバーの方々の名前出しちゃったけど、大丈夫ですよね？ｗ）
北海道と東北って、どっちも広いですし、海も挟んでいるので、結構物理的にも交通的にも距離があるんですよね。*1
なので、北海道・東北グループとして連携するような話になった時、最初は「いやいや、そんなん言っても連携なんて難しいでしょ？」とか思ってたんです。
全然、そんなことないですね。やはり、クラウドの世界に物理的な距離は関係ないですね。
使用したスライド
www.slideshare.net
反省など
まずは、プレビューが全然来なくて、内容は控えますが最後の手段を講じてなんとか5日前とかにゲットしまして、そういう訳で圧倒的に時間が足りなかったのですが、その中でも「まずParameterGroupを隅々見る」とか「実行計画を見る」とか基本的なアプローチを疎かにして、いきなり「仮説の検証」から入ってしまったのが失敗でした。やっていれば、もう少しためになる情報を出せたように思います。
次に、最初の概要とbioとかの提出のタイミングでは制限があるだろうことは把握していたのですが、思った以上に公開制限が厳しかったことが誤算でした。*2
なので、あくまで「公開情報を元に立てた仮説であり、答えは言えないけど、検証はしてるので見当外れではないはずだから自分で試してみてね」というギリギリのラインを攻めたつもりです。
ですが、答えを期待されていた方にはだいぶ物足りなかったかもしれませんね。申し訳ありません。
あと、Deep Diveの方ってことだったので、RDS及びMySQLはある程度知っていることを前提に、お互いの特徴を僕なりの目線で比較して解説しようというのが大筋の趣旨でした。
ですが、聞いてくれた知人の話ではけっこう( ﾟдﾟ)ﾎﾟｶｰﾝとしてる人が多かったそうです。
その辺り、今後は前提知識が必要な話をするときは最初にアンケートを取ってその場で比重を調節するみたいなプレゼンに慣れた方々がやるようなことができるように心がけたいなと思います。
今後
終わった後に日本でAuroraを担当をしているSAの@con_mameさんから、Auroraについての内部的なお話やAuroraへの熱い想いを聞きました。
それに感化されたというのと、久々にがっつりDB関係を触って自分の中の熱も上がってきたので、今後もAuroraは色々触ってフィードバックなりできるようにしたいなと思いました。*3
企業サポーターについて
右も左もわからず、スタッフの方々等に色々ご迷惑を掛けました。申し訳ありません…
ただ、今回で会社としてAWSやJAWSに対してよりコミットしていく兆しが見えてきました。
あと、個人的に社内向けな裏ミッションであった「名前とお金だけ出すのと、実際にコミットするのとでは全然違う」っていうことを身を持って示すことができたと思うので、良かったです。*4
最後に感想
JAWS Daysはもちろんのこと、JAWS Daysとは直接関係ない部分でも、今回の出張では今後が楽しみになるような出会いがありました。
そんな流れで、一応JAWSの中では若者の部類に入るので、今後新しい風を起こすような活動ができれば良いなと思います。
運営の皆様、本当にありがとうございました。お疲れ様でした。
去年からそうなんですが、お手伝いしたい気持ちはあるのですが、気がついた時にはだいぶ進んでしまっていて運営の方はちゃんと輪に入れずにいるので、是非早めにお声がけいただければと思いますm(__)m*5
