Serverlessconf Tokyo 2017で"Open source application and Ecosystem on Serverless Framework"というタイトルで発表してきました #serverlessconf

Serverlessconf Tokyo 2017に2日に渡って参加してきました!ワークショップも参加しました!発表もしてきました!以下レポートです!

Day1: Workshop

朝9時から夜9時までというハードコアなワークショップでした。

Serverless Tech Challenge with AWS Serverless Services

「本日のお題は

  • AWS以外のIaaS、PaaS利用禁止
  • 認証機構があること
  • 画像アップロード機能があること
  • CI/CDを回すこと
  • モニタリング機構があること

という条件のもと

  • 掲示板
  • SNS
  • マッチングアプリ
  • チャット

のどれかを作ってみよう。では、Go!」

という硬派な投げっぱなしジャーマンのようなチャレンジでした。

自分は、 comuttun さんと2人の急造チームでの参戦に。

まずは、お互いの自己紹介とAWSスキルを共有しあって、今回はサーバーレスについて自分が少し知識があったのでServerless Frameworkを使うことにしてもらいました。

Cognito User Poolを使いこなせない2人

なんと、Cognito User Poolの利用方法を2人でそれぞれ調べるというところからスタート(外部サービスが使えればOAuthとかでいろいろ省略できたのですがそれはNGだったので。。)。最悪なスタートです。

この時点で何を作るのかは未定。「とりあえず認証機構を実装できてから。話はそれから」という状況で、SAさんに質問しながら実装を進めました。

マッチングアプリとは何か

認証機構ができたところらへんで、いったんcomuttunさんが諸事情で離脱。

その間に容易に設計できそうなものとして、まずチャットを選択して設計しました。

  • チャットのメッセージ更新自体はロングポーリングで妥協。
  • コメントはJSONファイル、画像アップロードはそのまま画像ファイルで、時系列に並ぶようにS3にオブジェクトとして保存
    • /rooms/{roomName}/messages/{reversedUnixtime}.{json|jpg} (Reversed Timestamp ID)
    • 細かい情報はS3 Object Taggingに格納 (S3 Object Tagging)
  • あとはAPI Gatewayで各ルームのチャットメッセージのCRUDを作ればOK

というような、まさに今回発表予定だったTipsをフル活用した感じで設計。まあ、できそう。

掲示板やSNSはなんとなくRDBの無い世界では面倒そうということで、次設計してみるのはマッチングアプリかな?と思っていたところで、comuttunさんが合流。

チャットの設計を説明した上で、「そもそもマッチングアプリってなんだ?」という話に突入。

そう、2人ともマッチングアプリ自体を知らないという。。。

  • 「マッチングアプリってPairsとか?」
  • 「人と人をマッチングすればマッチングアプリ?」
  • 「いい感じで相手をリコメンドすればいいってことか」
  • 「要件として画像アップロード機能が必要だからセルフィーをアップロードしてもらって、Amazon Rekognitionで画像を解析して得たパラメータ使えば良いのでは?」
  • 「Male/FemaleパラメータとはHappyパラメータとかあるから良さそう」

という感じで「想像で」マッチングアプリを設計しました。

で、この時点で明らかにチャットアプリのほうが設計の精度は高くて「チャットかな」と思っていたら

comuttun 「Amazon Rekognition使ったことないし、せっかくだからマッチングアプリにしよう。面白そう」

という無謀な発言が飛び出て、ずっとコード書いてるハイテンションからか、そのまま採用されて

  • comuttun: Amazon Rekognition
  • k1LoW: API Gateway経由での画像アップロード

という分担で開発再開。

結果、見事に時間が足りず撃沈しました。

俺達はスケジュール管理ができない!あと2時間あれば機能は実装できた。。。!!

Introducing a new event-driven world with Serverless Framework

間髪入れずに次のワークショップに参加。

OSSなFaaSの体験と、Event Gatewayの体験というワークショップでした。

GCPの利用も初なのに、GKE -> k8s -> kubelessと盛りだくさんなOSS FaaS体験と、BigQuery + Event Gatewayというこれまた初体験づくしなEvent Gateway体験でした。

途中、最新VerのServerless Frameworkの不具合が発見されたりしましたが、後日 comuttun さんがなおしてPRを出していたという最高イベントも発生しました。

Day2: Conference

カンファレンスも最初から参加しました。

"サーバーレス"を語るときに僕が語ること

"サーバーレス"は未だに定義が曖昧で、たぶんこのまま曖昧のまま進んでいきそうな雰囲気ですが、「サーバ管理レスだけ考えているとPaaSに毛の生えたもので世界が終わっちゃうぜ」という話で、特に「例えばEvent Driven Architectureという文脈で考えてみようぜ」という話でした。

自分もいくつかサーバーレスなツールやアプリケーションを作りましたが、「良く」作るためにはそれなりに考える必要があります。そしてそれはいつものLAMPアプリケーションとは違うという。。

ここらへんがうまく言語化できたり体系化できたりすると、サーバーレスの世界から離れたときも活用できるアーキテクチャを得ることができそうな気がします。

個人的には、「削られた最後の1ページ」も公開して欲しかったですw

サーバレスアーキテクチャによる時系列データベースの構築と監視

個人的に楽しみにしていた発表です。

MackerelというSaaSのバックエンドの根幹になる時系列データベースを独自に再構築した、しかもAWSマネージドサービスをフル活用している、というのは個人的に非常にワクワクする話で、今までdiamondについて言及したブログエントリーや発表もずっとウォッチしていました。

それはあたかも(AWSがRDMSを新たに再構築してRDBMSの各構成要素を水平分割するという新たなアーキテクチャを編み出した)Amazon Auroraのようで、Redis -> DynamoDB -> S3という局所参照性に合わせてうまくデータが移動して保存される様は「めっちゃ考えて編み出したアーキテクチャだ」というのが分かって最高です。

そんなプロダクションで稼働しているdiamondの監視とチューニングについての今回の発表は、まさに「プロダクション」であり、勉強になりました。

Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤

www.slideshare.net

機械学習の話というよりもStep FunctionsとAWS Batchの実践的な知見の発表でした。むしろとても良かったです。

コンポーネントごとに説明があって、それぞれで活用できそうな雰囲気でした。

個人的にはこのあとスポンサーブースで聞いた「いかに管理コストを下げるか」についての熱い思いの話が面白かったです。

The mind of Serverless as a Software

slideship.com

既存のアーキテクチャの流れとServerlessはつながっているという話から、1つ1つステップを踏んで、実際に設計をしていく際の指標を「少し強めに」指し示してくれる発表でした。

FaaSとFunctional SaaSをしっかり定義した上で、それぞれのつまづきポイントを「分けて順番に」説明してくれたので、混乱せず、と同時にワードの理解もはっきりできました。

少しサーバーレスをかじった人に紹介したい資料です。

Open source application and Ecosystem on Serverless Framework

github.com

自分の発表です。

予想外に多くの方に聞いてもらえてよかったです。(書けない英語で一生懸命書いたのですが、残念、海外の方は会場に1名でした)

伝えたかったことは発表した順番とは前後しますが、

  • Serverless Frameworkはインフラからロジックまで1コマンドで展開できる強力なツール
  • 例えば、1コマンドでサーバーレスでフルマネージドなアプリケーションを展開できると、ユーザにとってはそのアプリケーションを構成する要素は気にならなくなる(=隠蔽される)
  • ユーザにとっては、あたかもその機能を提供してくれる「ミドルウェア」や「サービス」に見える(抽象化される)
  • また、例えば、1コマンドをさらにHeroku Deploy Buttonみたいにさらに簡略化すれば、OSSなサーバーレスなツールやアプリケーションの展開が広がるのでは?(そして実装してみた)
  • OSSな「サーバーレスミドルウェア」や「サーバーレスサービス」が多くでてきて開発を助ける世界が来て欲しい

という感じです。

ところで、質疑応答で「サーバーレスミドルウェアとマイクロサービスは同じでは?」という質問をもらいました。

そのとき、質問していただいた方にうまく説明できず申し訳なかったのです。

ちなみに個人的には「同じではない」というイメージです。

nekoruriさんがとてもわかりやすい説明をしてくれたのですが、「マイクロサービスは責務による分離、サーバーレスミドルウェアは機能による分離」というものです。

構成要素がマネージドサービスのみだったり(マイクロサービスではその限りではありませんが)、抽象化されて扱われるという点では同じかもしれません。

マイクロサービスは作りたいサービスの文脈に沿って分割・抽象化されているのに対して、サーバーレスミドルウェアは「ある機能を抽象化しようと構築されたもの」を指したつもりでした。

例えば、マイクロサービスの1要素は(おそらく)そのサービスの文脈に特化して実装されていますが、サーバーレスミドルウェアとして構築された「時系列データベース」は、時系列のデータを取り扱う機能を実現するために構成されているので、他の時系列を取り扱いたいサービスでも抽象化されたまま活用できる可能性があります。

もともと「サーバーレスミドルウェア」というか「抽象化されたミドルウェア」という考えは、はてなさんのdiamondに対しての発表とアーキテクチャを見て感じたことです。 1つのソースコード/サーバ上で構築されたわけではなく、マネージドサービスを横断して活用していて、それでいて「時系列データベースを作った」と表現しているのをみて「あ」と思いました。

faultlineの実装を通じて「SaaSっぽいもの(サーバーレスサービス)は作れる」という実感はありましたが( Serverless Meetup Fukuoka #1で発表 )、今回はそれをさらに推し進めて「サーバーレスミドルウェア」という世界もあるのでは?と思った次第です。

なんか、そんな、感じです。

その他

サーバーレスおじさんユニフォームをもらったり、サーバーレスの厚い本をGetしたり、スポンサーブースで時間の許す限り興味のままにいろいろ質問しまくったり最高でした。

ちなみに今回のハイライトはカンファレンス後の呑みで、1年ごしにhorike37さんにサーバーレスな相談をしたら、サーバーレス過激派の人や北海道のサーバーレスおじさんやEmacs実践入門の人にパラレルにつっこまれ、見事に爆散したことです。

Serverlessconf Tokyo 2017、カンファレンス運営の皆様、発表者の皆様、スポンサーの皆様、参加者の皆様ありがとうございました!

PHPカンファレンス2017でServerless Frameworkの話とoctopackageの紹介をしてきました #phpcon2017

今年もPHPカンファレンス2017で登壇させてもらいました。また、懇親会LTでもoctopackageの紹介(?)をしてきました。

サーバーレスアーキテクチャPHPアーキテクチャとの違いの話

この「Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見」という発表タイトルは、実はNulabさんが主催するGeeks Who Drinkで発表させていただいたものと同じです。

思えば、YAPC::Fukuoka 2017 Hakataに応募してリジェクトされて「まあそうだよね」とツイートしていたのをagataさんが拾ってくれて(!!!)実現したのが、Geeks Who Drinkでの発表でした。

nulab.connpass.com

そして、発表後にagataさんに「他でも発表したほうがいい」と言ってもらったので、PHPカンファレンス2017のCFP3つのうちの1つとして応募しました。

そしてまさかのこの内容が採択。

ただ、今回はPHPカンファレンスでの発表ということで、各ツールのデモをなくして「サーバーレスアーキテクチャに興味もってもらうこと」「LAMPアーキテクチャとの違いを感じてもらうこと」に力を入れてみました(後半は若干喋りたいことになっていますが)。


Japan PHP Conference Track3 (2) - Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見

詰め込みすぎた結果、思ったとおり質疑応答の時間はなかったです。

当日の反応としては「少しだけ」といったところでしたが、その後資料公開に反応してくれた方が多くいて安心しました。

懇親会LTと感謝

懇親会LTは、当日先着順なのですが、kaz_29さんに「どう?」と言われて、ちょっと伝えたいことがあったので応募しました。

発表者の方と動画配信チームのおかげでできたComposerプラグイン

今回紹介したoctopackageの概要はこちらをみてもらうとして、この懇親会LTでは直接感謝を伝えることができて良かったです。

動画配信があること

発表資料と動画配信があってはじめて現場にちかづく情報量になる発表もあります。動画配信は本当にありがたいです。

今年のshin1x1さんの発表などはまさにソレではないでしょうか。

かつて自分も、発表資料と動画配信を合体させて配信するというアイデアzenpreというものを作っていました。動画コンテンツを作るのがどれだけ面倒なのかは知っているつもりです。

昨年も含めて今年もooharabucyouさんが関わっていることを知ることができました。ありがとうございます。

そして、すみません。今年もooharabucyouさんの動画配信を期待している発表がいくつかあります。ベストエフォートでのんびりよろしくお願いします。

発表があること

そして、さまざまな領域の知見を共有してくれる発表者の方には感謝です。

今回はHirakuさんでした。packagist.jpやprestissimoなど、最近のPHPerの「速さ」に対する貢献は大きいです。

Composerプラグインの世界を知ることができて良かったです。

少なくとも自分は、PHPライブラリをoctopackageで効率よくリリースができるようになりました。ありがとうございます。

今年もPHPカンファレンスは最高でした

スタッフの皆様、発表者の皆様、スポンサーの皆様ありがとうございました!!

最高でした!

PHPカンファレンス2017でServerless Frameworkとその知見について発表します #phpcon2017

とうとう今週末はPHPカンファレンス2017です。

昨年は .ssh/config の世界の発表でしたが、今回は、流行りの「サーバーレスアーキテクチャ」周りの発表をさせていただきます。

session13: Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見 - Japan PHP Conference 2017 - Joind.in

PHPのカンファレンスでServerless Frameworkについて話すということ

今回もPHP成分はゼロです。とはいえ、せっかく発表するので参加者に何かしら持って帰ってもらいたいと思っています。

トークで、参加者の皆さんには以下のような知見を持って帰ってもらいたいと考えています。

  • サーバーレスアーキテクチャと呼ばれているモノの強力さ
  • Serverless Frameworkというツールを活用することで、より簡単にサーバーレスアーキテクチャなアプリケーションの構築ができるということ
  • 「サーバーレスアーキテクチャで作る」という中で生きてくる(LAMPなアプリケーション構築とは違う)設計やアイデアがあるということ

サーバーレスアーキテクチャは「イベントドリブンアーキテクチャ」とも言われたりします(こちらのほうがしっくりくるという人も)。

HTTPリクエストなどのイベントをトリガーにプロセスを立ち上げて、処理が終わったらプロセスを破棄する。それはまさにmod_phpが処理するPHPのようではありませんか。

強引な言い方をすれば、PHPerはサーバーレスアーキテクチャと親和性が高いかもしれません。はい、強引すぎました。。。。スミマセン

というわけで

「サーバーレスアーキテクチャとかちょっと新しいものにチャレンジしたいなー」という方、是非参加をお待ちしております。

おや、チャレンジといえばPHPカンファレンス2017のテーマが「Challenge」ですね。。。?

Serverless Meetup Fukuoka #1で発表してきました #serverlessfukuoka

とうとう福岡にもServerless Meetupがやってきました!

serverless.connpass.com

縁あって発表させてもらう機会をいただきましたので、技術というよりも事例的な感じで発表しました。

サーバーレスアーキテクチャはシステム間の糊的な役割としても使えるがシンプルなサービスを作るだけのポテンシャルはある

今回言いたかったのはこれだけで、実際にFusicでカジュアルに"SaaSライク"に運用している状況を具体的な数字で実感してもらおうと資料を作ってみました。

うまく伝わっているといいなと思います。

感想

@yoshidashingo さんの「サーバーレスについてのオーバービュー」を福岡で聴けたのは非常に大きいと思います。

www.slideshare.net

社内でも一部はまだ「サーバーレスって何?」という状況です。

ちょっとでも興味のある人が増えて、福岡でもいろいろ話すことができればな、と。

懇親会が最高だった

1次会は空気を読まず、 @yoshidashingo さんと @nekoruri さんの隣に陣取って、いろいろ聞きたいことを聞きまくりました(あんまりサーバーレス関係無かった気がする)

さらに、2次会はクラウドな会社の人たちに興味あることをずっといろいろ聞いていました。やっぱりレベルとか規模が違う。あとawspecへのPRのお礼とか。

というわけで

主催していただいた @yoshidashingo さんありがとうございます!いちおう私も主催側だったのですが、結果一番楽しんでいた気がします。

参加していただいたみなさんありがとうございます!

会場を提供していただいたさくらインターネット様ありがとうございます!さくらインターネット福岡オフィス最高です!

Serverless Conf Tokyoまた行きたい!

いかに危険なコマンド実行間違いを防ぐか。そのためにExeCopを書いてみた

追記: Bashにも対応しました

皆さんもpeco/percol/fzf/anyfinderなどのフィルタリングツールを便利に使っていると思います。

ちなみに私はpeco派です。

コマンド実行間違い

ところで、*sh_historyを使ったコマンド補完をpecoにまかせていて ( こういうの )、「コマンド実行間違い」をしてしまうことありませんか?

例えば、

  • bundle exec cap staging deploy のつもりが bundle exec cap production deploy を選択して本番環境へデプロイしまったり
  • docker container start xxx のつもりが docker container stop $(docker container ls -aq) を選択して全てのコンテナをストップさせてしまったり

pecoを経由した「フィルタリングして実行」があまりに便利なので、ついつい「フィルタリング -> 選択」をカジュアルに実施してしまい、結果、コマンド実行間違いが多くなってしまいました。

ちなみに、最近私がやらかしたコマンド実行間違いは、Roadworkerのテストを AWS_PROFILE=my-awstest bundle exec rake で実行するつもりが、AWS_PROFILE=k1low bundle exec rake で実行してしまい、プライベートのRoute53のHostedZone設定を全て消してしまったことです ( これ で簡単にテスト環境をつくれるようになったから。。。 )。

いつか、もっと危険なコマンド実行間違いをやらかしそうです。

ExeCopで危険なコマンド実行間違いを防ぐ

というわけで、コマンド実行間違いを防ぐためにExeCopという名前でzshスクリプトを書いてみました。

github.com

ExeCopは、.execop ファイルを設置しておくことで、そのディレクトリ以下で実行するコマンドを監視してくれます。

そして .execop ファイルに書いてある設定に沿ってコマンドをキャンセルしたり yes/no の確認フェーズをはさんだりします。

demo

インストール

execop.zsh を任意の場所にダウンロードし、 .zshrc に以下のように記述します。

. /path/to/execop.zsh

Bashの場合は、execop.bash を任意の場所にダウンロードし、 .bashrc に以下のように記述します。

. /path/to/execop.bash

.execop ファイルの設置

.execop ファイルは例えば以下のように書きます。

deny when command_match destroy
confirm when command_match rm
deny when command_eq rm -rf /
confirm when env_eq AWS_PROFILE=production

上記の設定だと、

  • コマンドに destroy という文字列が入っていた時、コマンド実行をキャンセルする
  • コマンドに rm という文字列が入っていた時、yes/no の確認フェーズをはさむ
  • コマンドが rm -rf / だった時、コマンド実行をキャンセルする
  • 環境環境 AWS_PROFILEproduction だった時、yes/no の確認フェーズをはさむ

という監視がはいるようになります。

例えば、TerraformのファイルがあるディレクトリでAWS_PROFILEに制限をかけたり、Capistranoのデプロイディレクトリでデプロイコマンドに確認フェーズを差し込むなどすると良さそうです。

.execop ファイルの監視設定のフォーマットは以下のような感じです。

[action] when [matcher] [command or environment value]

actionは denyconfirm の2つ。

matcherは今のところ command_match command_not_match command_eq command_not_eq env_eq env_not_eq を実装しています。

懸念点

ExeCopを導入するとコマンド実行のたびに監視処理が走ります( preexec )。

若干挙動が遅くなるかもですが、危険なコマンド実行間違いをするよりはマシなのでこのまま運用してみようと思います。

というわけで

危険なコマンド実行間違いにビクビクしている方は、 自己責任で ご利用ください。

ちなみに、皆さんはどのようにしてコマンド実行間違いを防いでいるんでしょうか。

Webフロントエンドハイパフォーマンスチューニングはサーバサイドエンジニア/デザイナも情報にインデックスをはるために読んでおいたら良さそう

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

私のフロントエンドスペック

まずは前提です。こういうスペックの人の感想ということでご了承ください。

  • 主にPHPでWebアプリケーションを構築するエンジニア
    • jQueryから少し脱しているくらい
      • 数年前まではフロントエンドにもステ振りをしていたが、仕事では最近は大人しくPHPなアプリケーションを構築している
  • 業務でもHTML/CSSでデザインしてくれるWebデザイナとのやり取りが多く、「フロントエンドエンジニア」とお仕事をしたことは数えるくらいしかない
  • サーバサイドのJavaScriptには最近興味あって触っている(サーバーレスとか)

つまりフロントエンド周辺については趣味プロレベルです。

感想

いやー、濃かった。一言で言うと「濃い」です。正直すべてを理解できたわけではないです。30%理解できていたら上出来です。

でも、読んで良かった!

個人的には

読むと読まないとではゼロイチで違う

そんな書籍でした。残り70%、またどこかで再読しようと思います。

仕組みを根拠としたチューニング

「ハイパフォーマンス」「チューニング」という単語があるように基本的には高速化の本です。

個人的には「ブラウザからサーバへリクエストを投げてからブラウザで次のページに遷移するまで」の仕組みを説明して「だから高速化になりうる」という形でチューニング方法を説明していて、どちらかというと「仕組み」のほうが勉強になりました。

フロントエンドエンジニアの人だったら逆なんでしょう。

むしろ、仕組みについてページをさいていたと思います。フロントエンドの基礎を学んだ感じがしました。

サーバサイドエンジニアにもWebデザイナにもフロントエンドのパフォーマンスのためにできることはある

少々乱暴な分類をします。すみません。

例えば、Webアプリケーションを「サーバサイドエンジニア」「フロントエンドエンジニア」「Webデザイナ」で構築するとします。

HTML/CSSは共通言語です。あとjQueryもいまや共通言語といえるかもしれません。

フロントエンドのパフォーマンス向上はフロントエンドエンジニアが一番得意でしょう。フロントエンドエンジニアに任せるのが一番だと思います。

ただ、だからといってサーバサイドエンジニアやWebデザイナから、何も考えず作られたHTML/CSS/JavaScriptを渡されてもパフォーマンス向上の余地は小さいと思います。

フロントエンドのパフォーマンス向上の余地をできるだけ広くするようにサーバサイドを構築したり、HTML/CSSを組んだりすることはできるはずです。

そういった意味で、サーバサイドエンジニアとして「フロントエンドの領域で○○に注意して構築することでパフォーマンス向上の余地を残しておく」という情報にインデックスを貼ることができる書籍でした。

そういえば思い出したのですが、昔、Webデザイナの方から「CakePHPのctp分離を完全に考慮したHTML/CSS」を渡されて、最高に効率よくデザイン適用と運用できた経験があります。最高にテンションがあがりました。

私もそういったバトンタッチができるようになりたいです。

章別感想

かんたんに章別の感想です。

1〜3章

本書を読むときにいろいろ前提となるので、まず読んでおいたほうが良い章です。3章の「計測」章は今すぐからでも使えますね。

ただ、まさかTCP/IPTLSハンドシェイクの説明からはじまるとは。。。。

4章

個人的に俄然面白くなった章です。

理由は明らか。自分の守備範囲だから(しかも知らないことがあった)。defer属性とか使ったことなかったです。

「できることはいろいろある」というのを感じることができた章でした。

逆に言うとあまり気にしていなかったんだなーと。

4章は「あー知ってる、知ってる」となりたかった。。。

5章

JavaScriptの別の世界。

「console.log()はメモリリークする」なんて、フロントエンドの世界では常識なんですか?

この章から著者 id:anatooさんの以下の発表が追加章的につながっています(と思いました)。こちらもどうぞ。

JavaScriptを書くとき、ここまでしっかり考えたことなかったな。。。

6〜8章

ざっくりいうとDOMの世界のチューニング。

CSSをどう組むかについて、私は良くて「メンテナンサビリティ」、大抵は「うまく表示できるか」程度しか考えられていませんが、パフォーマンスという観点でCSSを組む世界。。。

「子孫セレクタ、間接セレクタは他のセレクタよりもオーバヘッドが大きい」というかそもそも間接セレクタを知らなかったりしました。

9章

「認知的チューニング」ということで体感速度についてチューニングの章。一般的な手法について丁寧に解説しています。

こういった処理は実装時からうまく入れられるようにしていきたいです。

フロントエンド領域を知ることができる書籍

例えば「SPA」がもてはやされるようになっているように、フロントエンドと呼ばれる領域はますます重要になってくるんだと思います。

自分はフロントエンドエンジニアには(おそらく)ならないとは思いますが、フロントエンドエンジニアと一緒にうまく開発ができるエンジニアにはなりたいです。

本書「Webフロントエンドハイパフォーマンスチューニング」は、Webアプリケーション開発に関わっているエンジニア/デザイナ「も」フロントエンドの情報にインデックスをはるために読んでおいたら良さそうな本だと思いました。

最後に

本書は Geeks Who Drink にて、著者の id:anatoo さんから頂きました!

ありがとうございました!

さて、計測してみよう。。。

RoadworkerのテストAWS環境を構築するroadworker.tfを作成した

やっと重い腰をあげて、まずはテスト環境を構築できるようにしました。

RoadworkerのテストにはAWS環境が必要

RoadworkerはRoute53を管理できる構成管理ツールで、Codenize.toolsの1つです。

多くの企業で導入実績があり、また、十分なテストが書かれているので安心して利用ができます。当然のようにTravisCIによるCIも回っています。

では、そのテストはどのように実行されているかというと、作者である id:winebarrel さんのAWS環境で実行されています

.travis.yml をみてわかるとおり、最低限必要なAWSリソースとして

  • まっさらな Route53 ( RoadworkerがRoute53のHostedZoneから管理するツールのため )
  • VPC
  • ELB
  • CloudFront

があります。特にELBの月額費用は月額18USDと馬鹿にならない料金です。

それらを用意してもらっているので、PullRequestベースなら自前でテストAWS環境を用意しなくてもテストが可能です。感謝。

それでも自前の環境でテストを実行したい

とはいえ、新しい機能を追加したいときや、ちょっとした修正をPullRequestをしたいとき、事前にテストを実行したいものです。

無駄にPullRequestを出してテストを回しまくるわけにもいかず、TravisCIの順番待ちもちょっと効率が悪いです。

できれば自前の環境でもテストを実行したいです。

RoadworkerのテストAWS環境を構築するTerraformコード

というわけで、RoadworkerのテストAWS環境を構築するTerraformコードを作成しましたので共有します。

Test environment for Roadworker

使い方

必ずRoute53を利用していないAWSアカウントで実行してください

$ ls
roadworker.tf

$ terraform apply # Terraformを実行してAWS環境を構築
$ terraform output # Terraformのoutputを確認
AWS_REGION = ap-northeast-1
TEST_AWS_ACCESS_KEY_ID = XXXXXXXXXXXXXXXXXXX
TEST_AWS_SECRET_ACCESS_KEY = XXXxxxxXXXXxXXXXXXXXXXxxxxxxxXXXXX
TEST_CF = dxxxxxxxxxxxxx.cloudfront.net.
TEST_DELAY = 0.3
TEST_ELB = roadworker-test-000000000000.ap-northeast-1.elb.amazonaws.com.
TEST_INTERVAL = 3
TEST_VPC1 = vpc-x0x0x0xxx
TEST_VPC2 = vpc-00x0x0x0
TEST_VPC_REGION = ap-northeast-1

$ eval $(terraform output | sed 's/ //g' | sed 's/^/export /') # outputの結果を利用して環境変数をセット
$ cd /path/to/roadworker
$ bundle exec rake # Roadworkerのテストを実行

テスト環境が必要なくなったら terraform destroy で作成したAWSリソースを削除できます。

テスト環境を作成した経緯

実は、つい先日まで私が codenize-tools/roadworker に実質放置していたPullRequestがありました。

自分の環境で該当箇所のテストだけ実施して、いざPullRequestを出してみると他のテストでエラーになりました(この時点でマズいPRの出し方でした)。

しかし(プライベートなAWS環境は既にRoute53を使っていたので)テストを回すための環境がなかなか用意できず、エラーの検証もなかなかできず今に至っていました。

github.com

今回、やっとRoudworker用テストAWS環境を用意し、テストを利用して試行錯誤して、やっと「自分の修正の筋が悪そうだ」ということに気づけてCloseしました(すみません)。

やっとテスト環境を手に入れたので

またじっくり検証してみます。