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の皆さん、また発表者、参加者の皆さんありがとうございました!🍻

GitHubのプライベートリポジトリをストレージとして活用したシンプルなメモサービスhubeditを作っている

スマートフォンのブラウザからでもメモが書けるサービス

自分はいつも簡単なメモ書きにはEmacsか、ブラウザを開いていたら wri.pe を使っていました。

wri.pe を使い始めたのは2013年からで、かれこれ4年使っていることになります。

wri.pe で気に入っているところは

  • シンプル
  • スマートフォンのブラウザからもストレスなく使える
  • バックアップが自分がハンドリングできる場所に取れる(wri.peはDropbox

というところです。

いつでもどこでもブラウザがあれば雑にメモが取れるのが最高です。

ただ、ちょっと困っていることがあって wri.peは最近

  • ノートの検索機能が動かない (微妙に動いている!?)
  • ノートの削除機能が動かない

という状況が続いています。

これが地味に効いてきているので、「自分で作ってみようかな」という気持ちになって作りはじめています。

hubedit

hubedit.com

f:id:k1LoW:20170713071007p:plain

hubeditは wri.pe と同じように

を主眼に置いています。(まあ、つまり「自分が便利に使えるように」ということですね。)

特に「バックアップ」が特徴で、バックアップというよりもむしろバックエンドにGitHubのプライベートリポジトリを使います

OAuth連携したGitHubアカウントで my-hubedit というプライベートリポジトリを作ってそこをメモの保存場所とする、つまり、メモの操作を全部 git commit ベースで実施するというアーキテクチャです。

GitHubリポジトリということは、当然 git pull して手元のEmacsでメモを作成編集することも可能です。

つまりいつものソースコードのように、ローカルでの編集と git push による同期が可能。便利。

また、せっかくバックエンドがリポジトリなのでディレクトリにも対応しました。

アーキテクチャ

f:id:k1LoW:20170712231630p:plain

いわゆるサーバレスアーキテクチャで構築しています。

HTMLや、そのHTML上のJavScriptが叩くAPIから全てを、API Gateway / AWS Lambdaで実装しています。メモファイルの操作は全部GitHub API v3で操作しています。

とりあえず早く使えるようにしたかったので、今のところ画像は皆無で、CSSやFont、JavaScriptなども直書きか cdnjs ベースにしています(そのうち気が向いたらS3の静的Webサイトホスティングなども活用しようかと思います)。

取得したGitHubのOAuthトークンだけはS3バケットに置いていますが、これもS3バケットのライフサイクルポリシーで1日で消えるようにしています。

ストレージは各々のGitHubリポジトリなので、hubeditの利用をやめたいときはGitHubでOAuth連携をはずすだけで完了です。

まだ微妙な点

  • GitHub API + S3をバックエンドとしているのでレスポンスがもっさりしている
    • DynamoDBをつかったら少しは早い?まあ、あきらめている
  • メモの編集が2コミットに分かれている(削除と追加)
    • ちゃんとコミットを作りたい
  • Vue.jsを初めて使ったので、コードが微妙っぽい。JSファイルの読み込み方法も開発モードのまま
  • UIが雑。ローディングアクションすらない。
  • ロゴがない(またか)

というわけで

個人利用としてはまあ満足です。

とりあえずwri.peのメモを変換して git push したので、このまま本格利用してみようと思っています。

PUBLIC BETAとして公開していますので、興味ある方は自己責任でご利用下さい。

(これってもっとがんばって組んだら、GitHubリポジトリをバックエンドにしたチーム情報共有サービスなんて作れたりするんだろうか。)

YAPC::Fukuoka 2017 HAKATAに前後含めてフルで参加してきました #yapcjapan

Perlは全く書けませんが、YAPC::Fukuoka 2017 HAKATAに参加してきました!

最初から最後までフル参加者! @akase244 さんとも話しましたが最高でした!(いろんな意味で)

全然野菜

まずは、会社を早めに抜けだして濃い目のイベントYAPC::Fukuoka 前々夜祭(非公式)へ

pepabo.connpass.com

なんか「テレビで見た人だー」みたいな有名エンジニアの人がいっぱいいるし、話している内容も興味深かったです。

やっぱりWebサービスの運用は大変だし、だからいろんな技術で戦っているんだな、と。

一方、受託開発で戦っている自分は、やっぱり octopass の方に興味があって、@linyows さんに「@linyows さんの知らない(であろう)受託開発の世界(という名のユースケース)」を延々と話していました。

前々夜祭で既にビールが入りました。

前夜祭

椅子もありつつ立食でビール飲みながらLTを聞きながら「テレビで見た人だー」みたいな有名エンジニアを見ていました。

atnd.org

うまいぐあいに福岡勢じゃない人と話すことができて最高でした。

「言語オタクで新しい言語を〜」って言いながらPerl6が入っていないのは絶対ツッコミ待ちだったと思います。

自分もギョームと全く関係のないギジュツテキな話をLTでしたら

と言われる始末。プロトコルとかプログラミングの話をしたんだけどなー。

ちなみにスライドの最後はこんな感じでした。

f:id:k1LoW:20170706165419p:plain

!!7月22日、7月28日、福岡 Kieth Flackにてイベントあるので是非遊びに来て下さい!!最高な音をお届けします!!

YAPC::Fukuoka 2017 HAKATA

いよいよ本編。

諸事情により残念ながら実行委員長の開会宣言は聞けずじまいでした。

ただ、関係各所から伝え聞くところによると、「ウケてない」「スベってもいない」「そもそも笑いをとっていない」「普通」「ちょっと声が小さかった」とのことでした。 個人的には倍速LT芸人の力を発揮して欲しかったです。無理か。

セッション

Perlなセッションが多かったので心配だったのですが、そこは言語関係なく「フムフム」「おー」と聞ける楽しいセッションが多かったです。

実は、特に聞くセッションを決めることなくフラフラと移動したり移動しなかったりしてセッションを選択していたのですが、どのセレクトも良かったと思いました。

個人的な印象ですがYAPCのセッションって独特の雰囲気がありました。PHPカンファレンスやRubyKaigiとはまた違った感じでした。言語化できません。

あとSpecial Sessionも良かったです。内容については自分は福岡勢なので「そうだね」という感じなのですが、 @wats さんの絡みでなんか「福岡良い」という感じがしました。これも言語化できません。

ただ、すみません。やっぱり最も印象に残ったのは最後のKeynoteでした。ベストトークの投票最後まで待って良かった。

なんというか是非Togetterとかで他の人の感想もみていただきたいのですが、いろいろとひしひしと伝わってきました。

togetter.com

@dragon3 さんみたいな人がエンジニアとして存在しているからヌーラボさんは強いんだと思いました。

懇親会

他県のPerl Mongerの人たちとCPANの世界の話をずっとしていました。

自分はPackagistとかgemとかnpmとかはリリースしたことはあるのですが、CPANはありません。

他のそれと比べてCPANは敷居が高いイメージがあったのですが、CPAN Authorの皆さんと話してみて、

やっぱり敷居が高いと感じました。CPAN Testersヤバい。プレッシャー凄い。CPANリリースみんなウォッチしているってなんなの。

でも、やってみたい気持ちも生まれました。とりあえず「PHP使えるならPerl使えるよ」という言葉を信じてみようと思います。

2次会は次の日が早い @dragon3 さんを強引に引き止めて少し呑んだりしていました。最高だった。

その後

おもしろイベントがあったみたいなのですが、緊急対応で参加できず。。。

medium.com

感想

最初から最後までフル参加者で、カンファレンス前後含めて全部参加すると最高でした。

YAPCレベル高いなーという印象です。

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