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しました(すみません)。

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

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

Serverless Frameworkというかサーバレスアーキテクチャの話をGeeks Who Drinkで発表してきました #GWD_Nulab

@agata さんに良い機会をもらってビール片手に発表してきました! 🍻

nulab.connpass.com

requestIdleCallback() の話

@anatoo さんの発表。ブラウザ上で様々なリッチアプリケーションが動くようになってどんどん要求が増えていっているのだと思います。

requestIdleCallback() はブラウザのアイドル時間に様々な関数を実行できるというものらしく、Web Workerとの対比でわかりやすく説明してもらえました。

その時には用途を思いつきませんでしたが、Webブラウザ上で実装しているIDEなどには良さ気な機能だと思います。

Cacooの没実装の話

@hiramako さんの発表。没実装になった理由や採用された実装の対比など、とてもわかりやすかったです。その分「かなり苦労して開発してそう」という感想。

それだけにCacoo HTML5は楽しみです。

Kibelaを支える技術

@ihara2525 さんの発表。Blog + Wiki + αなKibelaの紹介。Fusicももっと大きくなったら社内共有サービスをこんな風に拡張すればいいんだろうか。

「技術的挑戦は精神衛生上必要」っていうのは最近特に思います。

Shifterの話

@tekapo さんの発表。Shiferの話でした。すごくスッキリわかりやすかったです。

対応できるWordPressWordPressはいろいろ拡張できるので)の範囲がどんどん広がることを期待しています。

Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見を共有してきました

早口なうえに(おそらく)時間オーバーをしてしまったという詰め込みっぷりでした。

本当はもう少し最後らへんの設計のアイデアの話をじっくり話したかったのですがやはり無理でした。。。

hubedit以外はすべてGitHubソースコードを公開しているので、アーキテクチャの図と見比べて「あー、こんな感じね」とみてもらえれば。

そして

じゃんけん大会で勝った!!!@anatoo さんありがとうございます!

まだ途中ですがじっくり読みたいと思います!


主催のNulabの皆さん、また発表者、参加者の皆さんありがとうございました!🍻