読者です 読者をやめる 読者になる 読者になる

まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

クラウドを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すための一冊

俺たちのリーダーこと @iara さんが著者に名前を連ねている、Amazon Web Services 実践入門を発売前に頂戴することができたので、御礼を兼ねて感想などをまとめさせていただきます。

twitter.com

www.amazon.co.jp


本書のカバー範囲と対象読者

本書は入門本と銘打たれている通り、IaaSと一部のマネージドサービスを紹介しつつ、UIとCLI両方での操作がまとめられています。
オンラインマニュアルにも同様のことは書かれているわけですが、本書では実際に手を動かしてみるにはこうしましょう、という切り口でまとめられているので "クラウドをこれから使いたい、でもどうやって触ったらいいかわからない" という人がまず写経的にやってみるのに適していると感じました。
他にも、 "今AWS使っているんだけどUIからポチポチとやっているだけだよ" という方がもう一歩深い使い方を学んでいくというところでも役立つと思います。
そういった側面が強いため、手順をまとめたマニュアル集といった趣になっており、事例や深く突っ込んだ使用法については言及されていません。

読んだ所感

リーダーの書いた5章を読んだ時に、"最近はむしろこういうネットワーク設計とかしなくなってきたな" と思ったところが気づきというか振り返りがありました。
従来のクラウド活用は、物理サーバとネットワークの設計をクラウドに持ち込んで再現するといった向きが多かったと思います。
自分自身がいち技術者としてクラウドを触り始めたのはIaaSであり、やはりそういった "既存技術をうまくIaaSに合わせていく" アプローチで作っていました。
最近のクラウド利用はそのようなVMを並べるところから徐々に、PaaS/SaaSを組み合わせてサービスを作る流れになってきています。サーバーレスアーキテクチャとか言われているようなやつですね。
PaaS自体はSalesforceGoogleのApp Engineに代表されるようなサービスが既に7年前くらいにはあったわけですが、その利点が広く取り沙汰されるようになってきたのはここ1〜2年かなと。
"as a Service" をうまく組み合わせてサービスを作る際には、IaaSでやっていたようなネットワーク設計は(PaaS/SaaSの陰に隠れて見えなくなり)利用者が考慮する必要がなくなるわけです。

とは言え "我々はクラウドフリーで常にVMと仮想ネットワークしか使いません" という主義の会社もあれば、"うちではas a Serviceをうまく組み合わせる人のことをインフラエンジニアって呼ぶよ" という会社もあるので、すぐに見えなくなるものでもないし、ましてネットワークの技術自体が無くなることはあり得ないのだけれど、うっかりすると触れる機会がどんどん少なくなっていくものになるなと。

そういった流れの良し悪しについては色々な言説ありますが、何を選べばよいかを判断できるような人材になったほうが、著者の言う "もっと生産的で有用な時間を確保できる" ようになると考えます。

おわりに

"Amazon Web Services実践入門" はAWSを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すのにちょうど良いでしょう。
今の時代、"How"はAWSに限らず掃いて捨てるほど存在しているので、適切に選びとってサービスを作っていけるステップとして本書を使うと有意義だと考えます。

最後に、本書を贈っていただきました @iara さんに感謝申し上げます。ありがとうございました。

JAWS-UG Meguro #2 で "今更聞けないストリーム処理のあれとかこれ" というLTをしました。

最近はAzureをよくさわるんですが、AWSも引き続きホットなのでJAWS-UG Meguro #2へ行ってきました。
単に行くだけというのも面白くないので、最近いろいろ調べているストリーム処理回りについて一度整理しておこうということで、基盤と技術選択についての簡単なまとめをLTしたのでここに貼っておきます。

www.slideshare.net

これから始めたい人で、よくわからないけどとにかく始めて何かしら可視化したいという人は引き続き Azure Stream Analytics をお勧めします。

次回テーマは運営のAWS SAの方に希望を言うと良いそうです。
個人的にはAWS上でのネットワーク設計とかいろんな人の話を聞いてみたいかなと思ったりします。

YAPC::Asia 2015でAzureの話をした件とハッカソンの運営をした件

YAPC::Asia 2015 での発表

  • Discover the Microsoft Azure と題して、Azureの特徴ある "as a Service" の紹介と、その基盤について入門的な発表をいたしました。
  • 以前 "今後は複数クラウド事業者が提供するサービスを組み合わせて開発する流れが加速する" と書いたかと思いますが、各社特徴あるサービスがどんどん出てきており、かなり選択の幅は広がってきたと思います。
  • 今回紹介したPowerBIなんかを試してみたいという方は、下記の記事をご覧いただくのが手っ取り早いかと思います。 qiita.com

ハッカソンの運営

  • 2013年にも運営をさせてもらったわけですが、今回はGitHubさんの協力もあって、内容がかなり充実したものになりました。
  • YAPC::Asia 本編でトークのあった、Ben OgleさんのElectron話と、mizchiさんの開発話(から発展して逆質疑応答になっていたのは面白い展開でした)
  • 普段交流のない人とも交流ができて、いろいろとインプットを得ることができました。

所感

昨年 YAPC::Europe に参加した話をしたところ、今年は日本から8名(‼)参加するとのことで、いい流れだなと思います。 これまでの運営形態でのYAPC::Asiaはいったん終了という話ですが、builderscon.ioの発表もあり、カンファレンスは今後も盛り上がっていくといいなと思いますし、微力ながら協力できることは積極的にしていきたいです。

牧さんをはじめ、スタッフの皆様、とても良いイベントをありがとうございました。 過去最大の会場規模でも平和裏に進んだのは凄いことだと思います。

個人的なハイライト

  • SUZURIさんとmotemenさんの発想が完全に一致 f:id:myfinder:20150824114842j:plain

Microsoft に入社しました

失業エントリからはや1ヶ月、新しいチャレンジとしてこの5月から Microsoft で働くことにしました。

前職では "どスタートアップ" からいっぱしの上場企業になるまでのサービス基盤をやり遂げることが出来ました。

が、ここ半年ちょい、運用系仕事を減らしていた最中は “開発シフトしていきたい” みたいなことを思ってはいたのですが、失業して時間ができたので改めて振り返ってみて思い直したのは “自分はやはり基盤側の方により興味関心が強い” ということでした。
また、ハウジングの物理基盤から IaaS + SaaS へ移行させる取り組みをして感じたのは “開発技術や運用基盤の選択は生産性と俊敏性をより重視すべき” というものでした。

実際 AWS で EC2 を使っているユーザが BigQuery で集計/分析したりするような事例は沢山出てきており、SaaS, PaaS をウマイこと組み合わせてサービスを構築する流れがますます加速するでしょう。

そういった考えに立つと開発技術から運用基盤であるクラウド、果てはコンテンツ配信基盤まで持っていてサービスライフサイクルのほとんどを受け入れられる Microsoft の動向にひっそり注目するようになっていました。

元々 Microsoft に限らずクラウドの向こう側に興味関心はあったわけですが、たまたま中の人にお話を伺う機会があり、幸いにもオファーをいただけたこともあり飛び込むことにしました。
振り出しは国内でクラウド関連の仕事をすることになりますが、よりパフォームできれば場所にこだわらずにチャレンジしていこうと思っております。

今後ともよろしくお願いします。

あ、肉とか鮨のお誘いは引き続き歓迎いたしております。

ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話

はじめに

このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。

まとめ

昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。

クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。

そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。

発表資料&箇条書きで振り返る最近の動き

AWS Casual Talks #3

  • https://github.com/myfinder/aws-casual-3/blob/master/slide.md
  • クラウドに移すことを決めて、opsリポジトリを作って色々まとめ始めた頃
  • この頃はまだAutoScalingとかやってなかった
  • 毎度インスタンスを差し替えるのではなく、Ansibleで継続的にconfigを更新するやり方をしていた
  • ログ集計をオンプレのHiveから、Redshift or BigQueryどっちでやるかを検討していた時期
  • セットアップが面倒なものをDockerで運用したら楽になるんじゃと思って使い始めたのもこの頃
  • 実際Docker使うと楽になった

AWS Advanced Users Meetup vol.2

  • https://github.com/myfinder/aws-advanced-users-meetup-2/blob/master/slide.md
  • このタイミングから、Ansibleを継続適用するのをやめ、イミュータブル方向に一気にかじを切った
  • デプロイを種サーバからでなくS3から行うようにしたのもこの頃
  • AutoScaling対応をして、弾力的なアプリサーバの運用ができるようになった
  • 結果として、いわゆる “Infrastructure as Code” を実践することになった
  • Mackerelの威力を思い知った
  • この時注意していたのは “必要以上にクラウド側特有の機能に頼らない(学習を必要としないようにする)” ということ、これが後々、別のソフトウェアエンジニアへの情報共有で重要なポイントになった

Mackerel Meetup #3 と Monitoring Casual Talks #7

  • https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md
  • ここでこれまでの総まとめ的な発表をした
  • モニカジ7では “インフラエンジニアが死んだ” というタイトルで失業した話をした
  • この頃には今までやらなくてはいけなかった仕事の大半がなくなった
  • この後は細かいチューニングやら、ちょっとイケてない部分や余計な手順を省く仕事をしていた

直近の改善

  • Dockerコンテナでデプロイしていた諸々をすべてPacker->AMIという形に変え、Dockerを使うのをやめた
  • この方がすべてのコンポーネントをソフトウェアエンジニアが把握しやすいというのが理由
  • DockerコンテナもPackerから作ることができるので、最初からDockerでやるよりも汎用的だし未来の可能性を狭めない
  • packer build時にServerspecを使って、セットアップ状況をチェックできるようにした
  • ピークとそうでない時のトラフィック差が大きいサーバは Spot Instance 使うようにしてコストを大幅に引き下げた
  • AutoScalingが走っている時にdeployすると、タイミングによっては古いコードのままサービス投入されてしまう問題があったのでデプロイロック機構を入れる
  • 更に増えていく機能やデータをうまいこと扱うため、DynamoDBとその周辺ツールセットの検証と引き継ぎ

結果

  • “どオンプレ” だった環境が下記のような技術要素に置き換わり、スケーラブルで、かつソフトウェアエンジニアだけでコントロール可能で柔軟さと機動力をあわせ持ったシステムに生まれ変わった
  • サービス監視/インスタンス管理をMackerelで
  • インスタンスのセットアップやAMI作成をPackerで
  • セットアップ状況の保証をServerspecで
  • トラフィックが上下する部分はAutoScalingで
  • 量の多いログ集計はBigQueryで
  • ほとんどコードで管理できるようになり、新しい取り組みにソフトウェアエンジニアがチャレンジしやすい環境ができた
  • かくしてインフラおじさんとしてやっていた仕事をおよそ無くすことができ、更に運用コストも大幅に減らすことができ、私は堂々失業することになったのだった

とても大事なお知らせ

このエントリにある取り組みをしたエム・ティー・バーン社のAppDavisというサービスはいま絶賛成長中であり、機能開発がとても活発です。

↑に書いたようなチャレンジにも大いに理解のあるチームで開発をしたい ”腕の立つITエンジニア(特にスマホとサーバサイド)” を募集しています。

ご興味、ご関心を持っていただけた方は気軽に 社長 に声をかけるか、 こちらのフォーム から "エム・ティー・バーンの話を聞かせろ" と送ると良いでしょう。

www.fout.co.jp

おわりに

丸2年エントリでも書いたことですが、自分がこれまで取り組んできたことで重要な点は “開発/運用の品質/スループットを上げつつコストや納期を勘案して、サービス展開の可能性を最大化する” ということだったように思います。

今回のチャレンジでは、振り返ってみると意識していた原則が2つあって "何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” "ボトルネック以外触らない" というもので、それが結果として自分の仕事を無くすことにつながっていったわけです。

そういうわけで、今後はもっと違うことにチャレンジしていこうと思っております。今後とも何卒よろしくお願い致します。

今年出たもののまとめ

まとめ

  • 前半は "どオンプレ、ちょっとだけクラウド" をずっとやっていたが、後半はその自分で作ってきた "どオンプレ" からクラウドに移す仕事をしておりました。
  • 来年はもっと違うことにチャレンジしていきたいと思っております。
  • とはいえ、今年やったことは1月のMackerel Meetupで話をします。

Fluentd と Norikra をもっとカジュアルに使おう

Norikra とは

Norikra とはリアルタイムイベントストリームに対して SQL ライクな言語で処理できる cool なプロダクトです。

例えば、Nginx のアクセスログを Norikra に流し込み、n分あたりのアクセス数やレスポンスタイムをリアルタイムに集計するといった事が可能です。
もちろん Nginx だけではなく、ご自身が書かれたアプリが出力するログも流し込んで集計できます。

更に Fluentd を組み合わせると GrowthForecast や Mackerel といったツールに集計結果を渡して可視化するなどといったことも容易なので、速報値集計やシステム運用状況の可視化に持ってこいです。

Fluentd と Norikra を活用して可視化する例

fluent-plugin-norikra と可視化ツール(GrowthForecast等)を組み合わせるとすぐに可視化できます。

fluent-plugin-norikra では in/out 両方とも実装されており、"Norikra へデータを入れる" "Norikra で実行されたクエリの結果を取り出す" 事が簡単にできます。
例えば広告配信などで毎分の配信結果やクリック、コンバージョンの速報値を可視化したいといった向きにマッチします。

今回の例では、仮に下記のような体裁のログを log.ad として forward することを想定します

{ "time": 1417886121, "ad_id": 100, "spot_id": 1234, "publisher_id": 4321, "charge_price": 100, "payment_price": 50 }

Norikra は事前にスキーマ定義を設定しておく必要はなく、データを送れば自動的にテーブルを作ってくれます。
データ型を明示的に指定したいときは auto_field 設定を false にし、登録する内容を明記することもできます。
このログの場合すべて整数なので、integer として扱われます。

Norikra へログを送信する場合、fluentd の設定ファイルには

<match log.*>
  type    norikra
  norikra norikra-server:26571

  remove_tag_prefix log
  target_map_tag    true
</match>

と書いておくだけで、Norikra 側には自動的に ad テーブルが作られます。

Norikra にデータが送られたら event(SQLライクなやつ) を登録しましょう、例で指定したタイムウィンドウ毎にクエリ結果がためられていきます。
event にはグループ名とターゲット名を指定する必要があり、このグループ名やターゲット名を使って、処理した結果を受け取ることになります。
今回は ad_request_count_1min としておきましょう。

select count(*) as count from ad.win:time_batch(1 min)

そのクエリ結果を取り出すには、fluentd 側で下記のような設定をしましょう。

<source>
  type    norikra
  norikra norikra-server:26571
  <fetch>
    method   event
    target   ad_request_count_1min
    tag      string ad_request_count_1min.all
    interval 60s
  </fetch>
</source>

ここまでで取り出した結果を別の plugin (例えば fluent-plugin-growthforecast) に渡してグラフを作れば、簡単に可視化することができます。
この程度の可視化であれば、fluent-plugin-datacounter を使っても同じことができますが、複数のログストリームを JOIN したり、項目で(例えばホストごと) GROUP BY などする際には fluent-plugin で頑張るよりも手軽です。
また、fluent-plugin では集計対象を登録、削除する際に再起動が必要ですが、Norikra は再起動無しに追加削除が可能なので、運用上も手間が少ないという利点があります。

筆者はこういったログから配信状況の推移や売上/支払の速報値について、Mackerel のサービスメトリックを用いて可視化しています。

<match request_count_1min.all>
  type mackerel
  api_key api_key_string
  service ServiceName
  metrics_name request_count_1min.${out_key}
  out_keys ad_request_count_1min,appimp_request_count_1min,imp_request_count_1min,click_request_count_1min,conversion_request_count_1min
</match>

f:id:myfinder:20141207024717p:plain

更にカジュアルに使うために

オフィシャルサイトに案内がある通り、インストールには jruby が必要です。
Norikra だけを動かすサーバが用意できるなら、jruby をインストールしてほげほげするのも容易ですが、

"ちょっと試そっかなー、でもあのサーバだと他に ruby が必要なコンポーネントとバッティングするしな〜"

というふうな状況に二の足を踏んでいる方もいらっしゃるのではないでしょうか。
そんな二の足を踏んでいる皆様がもっとカジュアルに Norikra を使えるよう、Docker Hub に Dockerfile を用意しました。


myfinder/docker-norikra Repository | Docker Hub Registry - Repositories of Docker Images

Docker がインストールされ、稼働している環境であれば下記コマンド一発で Norikra が動き始めます。

docker run -d -p 26578:26578 -p 26571:26571 -v /var/tmp/norikra:/var/tmp/norikra:rw -t myfinder/docker-norikra norikra start --stats /var/tmp/norikra/stats.json -l /var/tmp/norikra

これで人類は Norikra のインストールをどうするかという悩みから開放され、どこでも気軽に動かすことができるようになりました。
(Norikra 自体の詳しい使い方はオフィシャルサイトをご覧ください)

今後もこの Dockerfile は upstream に追随して更新していく予定ですが、自分で管理したいという方はどんどん fork するといいのではないかと思います。
あるいはいずれオフィシャルに Docker Image が提供されるようになるかもしれません。その時はオフィシャルの方を喜んで使いましょう。