GoでWebアプリケーション作る練習をした

GoでWebアプリケーションを書いてみる練習として RequestBin ぽいものを試しに作ってみた。gomibakoという名前であまりひねりはない。以下のURLで試せます。

https://gomibako.douzemille.net/

ソースコードもGitHubに公開してある。

github.com

何ができるか

HTTPリクエストを受け付ける用のURLを作ることができて、そのURLに対するHTTPリクエストのログをWeb上で確認することができる。ちょっとしたWebHookの動きのチェックとかリバースプロキシの設定確認とかに使えて便利。

具体的には以下の様にして使える

  1. https://gomibako.douzemille.net/ にアクセスして "New Gomibako" ボタンを押す
  2. https://gomibako.douzemille.net/g/deadbeaf123/inspect みたいなURLが作られてリダイレクトされる。このページにログが表示される。
  3. 画面に表示されている、https://gomibako.douzemille.net/g/deadbeaf123 みたいなURLに別のタブやcurlとかでHTTPリクエストを送る
  4. 2で表示したページに今アクセスしたHTTPリクエストが表示される

ログ画面は以下のような感じになる。

f:id:hakobe932:20161125120132p:plain

HTTPアクセスがあるとリアルタイムにログが更新されるようになっていてるのが、ちょっとおもしろい。TwitterにURLをながすといろんなクローラが次々とやってくるのがリアルタイムに楽しめる。

なんか怖いのでHTTPリクエストのログは永続化していない。URLごとに最新10リクエストしか保持しないし、URLを作ってから一時間経つとそのURLは破棄されて使えなくなる。

ちょっとリクエストの様子を調べられるところが欲しかったので、自分としては満足してる。これまではリクエストログをダンプするだけのちっちゃいWebアプリケーション(app.psgi 3行くらい)を使ってたけど、いまいち使いづらかった。

技術的見どころ

習作という感じであまり見どころはないけど、せっかくなので紹介します。

Webアプリケーションの構成するGoのライブラリ

GoのWebアプリケーションフレームワークは多種多様で選択肢は豊富なものの、Goの net/http パッケージがしっかりしているので、あんまり分厚いフレームワークは使わずに済ませたほうがシンプルで良さそう。ということで最低限のライブラリで構成してる。

  • httptreemux
    • さすがに net/http のルーティングは機能が貧弱なのでつかってる
    • HTTPルータの実装もいろいろあるけど、速度やメモリフットプリントのパフォーマンスを優先して機能が足りないのも多い
    • httptreemuxはまぁまぁバランスが良さそう
  • negroni
    • 一番うすそうなミドルウェア実装かな、と思って選んだ
    • ミドルウェアのインターフェースも独自の型とか使ってなくてリーズナブルな感じ
  • secure
    • セキュリティ関係のヘッダをいい感じにつけてくれる汎用のミドルウェア

これくらいでだいたい困ってないし、とくていのライブラリへの依存度も高くないので結構いいんではと思ってる。セッションとか、データベースへのコネクションとかのグローバルステートの管理とかしたくなってくると、もうすこしいろいろ入れたくなってくるのかもしれない。もっと複雑なGoのWebアプリケーション開発している人の知見も知りたい

GoによるSever Sent Event の実装

リアルタイムにHTTPのログをページに出すために Server Sent Event を使ってる。Goの net/http はevent-streamのエンドポイントもちゃんと実装できるようになっている。

実際のコードはこのあたり:
https://github.com/hakobe/gomibako/blob/master/main.go#L148-L194

HTTPのハンドラの最後で無限ループを作って、その中でeventを書き込むようにしてしまえばコネクションは切断されない。ブラウザ側にもevent-streamってわかるヘッダをはいてやればコネクションは維持される。ただし、リバースプロキシがコネクションをタイムアウトさせたりということはあるので、コネクションが途中できれても良いようにはする。

コネクションははりっぱなしなので、書き込みバッファリングのフラッシュのタイミングはある程度制御してやる必要がある。http.ResponseWriterをキャストして、http.Flusherを作ってeventの書き込みごとにフラッシュしてやると良い。

おなじくhttp.ResponseWriterをキャストして、http.CloseNotifierのオブジェクトを取得すると、HTTPコネクションが切れたときに何かしらの処理をすることができる。

コネクションの管理はchannelを使ってがんばってやってる。リクエストを受け付けるURLに対応するオブジェクトが直接channelを管理するという雰囲気になっていて迫力がある(このあたりのコード >
https://github.com/hakobe/gomibako/blob/master/lib/gomibako.go#L32 )。mutex使っててこのへんのコードはむずくなっている。

channelはGoにおいてはファーストクラスのオブジェクトだけど、ドメインレイヤで扱うのはよくなさそうな感触。かなり実装の都合に依存するので、インフラストラクチャレイヤで管理したほうが良さそう。まぁこのプロジェクトでは、リポジトリっぽいレイヤしかなくてごちゃごちゃしている。interfaceとかおしゃれに使いたい。

まとめ

GoでWebアプリケーション書く練習をしてみて何かしら便利なものはできた。また、界隈にどういうフレームワークあったりするのかとか、net/httpの便利具合などはよくわかった。

一方、DBにリクエストしてテンプレートにいろいろレンダリングするみたいな、普通っぽいWebアプリケーションを題材に選ばなかったので、DBの管理の感じとかレイヤの設計とかあんまり気にせずにベロっとつくってしまった。Sever Sent Event を実装するところとかを主にがんばったけど、その知見の使い所は少なそう。interfaceをいいかんじに使って関心事を分離したい人生だった。

次は日記システムとかを作るといいんだろうかな。GoでWebアプリばりばり作ってる人いたら知見教えて欲しい。

立ち居振る舞い: チームのエンジニアに話しかける

ひとでくんがエンジニア立ち居振舞いお題を作っていたので参加します。

時々同じチームのエンジニアに話しかけるようにしてる。各エンジニアがやっているタスクはGitHubのissueの説明をみればだいたいわかるという設定だけど、話しかけて何やってるかを教えてもらうと良いことがある。

話しかけた時、だいたい相手はうまくいってるか、うまくいってない状態になっている。うまくいってる場合は、よく書けたコードとか工夫した設計とかについて教えてもらえて、なるほどな〜と勉強になる。うまくいってない場合は、聞き役になって困りごとを説明してもらえれば問題の整理に役立つかもしれないし、運がよいとアドバイスすることもできる。

当然、集中しているときに声を書けるのはご法度なのでタイミングを見計らうのが必要になる。狙い目は昼休みが終わった直後とか、終業間際とか仕事に一段落ついてそうなときが良い。相手が席をたって帰ってきたときとか。とにかく集中を乱さないようにする。相手が普段集中しているときはどういう雰囲気かとかを観察しておくと安全度が高まる。わざと自分が共有スペースをうろついて逆にスキを見せるという技もある。

基本的にエンジニアをインタラプトしてはいけないけど、何とかうまいことやって会話すると知見共有ができたり問題解決に役立つかもしれないし、会話していくのは大事ですよねという普通の話でした。もしめっちゃ邪魔になってたらこれまですいませんでした... > チームメンバー

みなさまの立ち居振舞いを教えてください!

お題「エンジニア立ち居振舞い」

HTTPSのWebサーバを設定した (h2o + Let's Encrypt)

最近、ハイパフォーマンスブラウザネットワーキングを読んでいて、HTTPSについてちょっと勉強しています。勉強にあたっては、実際に試せる場所があったら便利そうなので、自分のさくらVPSにHTTPSのWebサーバを設置してみることにしました。この次はHTTP2の実験もしたいので、先進的なHTTP2の機能が実装されていそうなh2oを使ってみることにしました。

環境

今回の作業は以下のような環境でやりました。

$ uname -a
Linux douzemille 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

準備

このあとの作業のために以下くらいのパッケージをいれておきます。h2oのmruby機能を使わないのであればruby系とbisonは不要。rotatelogsコマンドのためにapach2-utilとかもいれてます。

  • cmake
  • build-essential
  • libyaml-dev
  • ruby
  • ruby-dev
  • bison
  • letsencrypt
  • apache2-utils

h2oのビルドとインストール

オフィシャルのドキュメントが丁寧なのでその通りにやりましょう。この手順で、/usr/local以下にインストールされます。

$ ghq get h2o/h2o
$ ghq look h2o/h2o
$ git checkout -b build v2.0.4
$ cmake -DWITH_BUNDLED_SSL=on .
$ make
$ sudo make install

h2oの基本的な設定の準備

Let's Encrypt でHTTPSの鍵を取得するためにstaticなファイルを配信するためのHTTPサーバが必要なので、そのためのh2oの設定を用意します。/usr/local/etc/h2o/h2o.conf.ymlとか好きなところに置きます。

pid-file: /run/h2o.pid
error-log: "| rotatelogs /var/log/h2o/error.%Y%m%d 86400"
access-log: "| rotatelogs /var/log/h2o/access.%Y%m%d 86400"
listen: 80
hosts:
  "hakobe.douzemille.net:80": # 自分のドメインにする
    paths:
      /:
        file.dir: /home/yohei/web/hakobe # 配信されるファイルのおいてあるパスを指定

h2oをデーモンとして起動するためのsytemdのunit定義を準備

最近のUbuntuはsystemdというやつでデーモンの管理をしているそうです。h2oをsystemdの管理下で動作させるために、/lib/systemd/system/h2o.service に以下のような内容のファイルを置きます。h2o systemd service file作った - うま味がない をめっちゃ参考にしてます、というかだいたいコピペです。

[Unit]
Description=H2O the optimized HTTP/1, HTTP/2 server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/h2o.pid
ExecStartPre=/usr/local/bin/h2o -c /usr/local/etc/h2o/h2o.conf.yml -t
ExecStart=/usr/local/bin/h2o -c /usr/local/etc/h2o/h2o.conf.yml -m daemon
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

ファイルをおいたら以下のようなコマンドで有効化します。

$ sudo systemctl enable h2o.service
$ sudo systemctl start h2o.service
$ sudo systemctl status h2o.service # これでログが見れる

ここまでで80番ポートでHTTPのサーバが起動している状態になっています。設定ファイルに書いたディレクトリ(この手順では/home/yohei/web/hakobeにファイルをおいてうまく配信されているか確認しましょう。

Let's Encrypt からHTTPSの鍵をもらう

決められた手順でLet's Encryptとやりとりすることで、Let's Encryptによって署名されたHTTPSの鍵を取得できます(How It Works - Let's Encrypt - Free SSL/TLS Certificates で詳しい仕組みが紹介されています)。自動化されていているので、コマンドを実行するだけですぐに完了します。

ドメインの所有者であることを証明するために、そのドメインでアクセスできるHTTPサーバから鍵を配信する必要があります(そしてもちろんドメイン名から今設定しているサーバのIPが引けるように設定されている必要があります)。ここまででh2oがstaticファイルを配信できるように設定してあるので、コマンドラインのオプションから -wオプションでファイル配信元のディレクトリを指定します。

$ sudo letsencrypt certonly --webroot -w /home/yohei/web/hakobe -d hakobe.douzemille.net

これで /etc/letsencrypt 以下に鍵や設定が保存されます。よくできてますね。

追記: ちなみにここではletsencrypt というコマンドを使っていますが、最新版では名称が変わってcertbotというコマンドになっています。certbotのほうが高機能なようですが、基本的な動きは変わらないようです。certbotのページから自分の使っているOSを選択するとインストール方法を紹介してくれます。Ubuntuの場合はapt-get install letsencryptせよと言わるのでしたがっています。

Let's Encrypt の鍵を定期更新する

Let's Encrypt の鍵は3ヶ月でexpireします。必要に応じて更新する手順も自動化されているので sudo crontab -eとかして以下のように書いておきます。

0 4 * * * letsencrypt renew

h2oでHTTPSのサーバを起動する設定

はじめに作って、/usr/local/etc/h2o/h2o.conf.ymlとかにおいてあった設定を書き換えてHTTPSで動作するようにします。

pid-file: /run/h2o.pid
error-log: "| rotatelogs /var/log/h2o/error.%Y%m%d 86400"
access-log: "| rotatelogs /var/log/h2o/access.%Y%m%d 86400"
listen:
  port: 443
  ssl:
    certificate-file: /etc/letsencrypt/live/hakobe.douzemille.net/fullchain.pem
    key-file: /etc/letsencrypt/live/hakobe.douzemille.net/privkey.pem
    cipher-suite: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
    cipher-preference: server

hosts:
  "hakobe.douzemille.net:443":
    paths:
      /:
        file.dir: /home/yohei/web/hakobe

あれこれ書いてますが、

ということをしています。省略してますが80番ポートもlistenして、httpsのURLにリダイレクトしたり Strict-Transport-Security ヘッダを付けて返したりすると良いです。

できました

f:id:hakobe932:20160923180015p:plain

とくに何か情報のあるWebサイトではないのですが、とにかくHTTPSで配信できるようになりました。h2oを使っているのでHTTP2も喋れているようです。(HTTP/2 and SPDY indicator - Chrome Web Store で確認しています)

https://hakobe.douzemille.net/

SSL Labs によると A くらいの評価の設定にはなっているようです。がんばればA+になるらしいけどまずはこんなもんで。

f:id:hakobe932:20160923180137p:plain

これでとにかく現代的なインターネット基盤を実験してみる環境が整いました。めでたいですね。

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ISUCON6 に参加して無事洗礼をうけてきた

id:hitode909 くんと id:hatz48 さんの三人のチーム「C0-100%」としてISUCON6に参加した。初参加者のみのチームで言語はPerl。普段会社では良い設計考えたり開発フローいい感じにしていこうみたいなのが得意なメンバーで、今回もテスト書いたりCIまわしたりするいつも通りの開発でやっていくぞというテーマで参加した。

結果としては、最高38000点くらいまでいったものの予選敗退。最終スコア計算の時点ではほとんどFAILしてる感じで、300点くらいだった。トホホ。

我がチームの様子はhitodeくんのエントリが詳しい。

blog.sushi.money

担当

自分はサーバオペレーションを担当した。わりとすぐやることがなくなってきたので、アプリケーションコードを書いていた。

チームメンバーはみなアプリケーションエンジニアで、普段からインフラ的な仕事をしている人がチームにいなかった。誰かが特別得意ということもないので、とりあえず担当決めて事前に準備してやるという感じだった。

幸い今回の問題はそんなにサーバオペレーションが効くという雰囲気でもなかったので、過去のISUCONの回答例などを参考にミドルウェア類を整備するという感じでなんとかなった。kazeburoさんの設定をどんどん入れていくという感じ (
ISUCON4 予選でアプリケーションを変更せずに予選通過ラインを突破するの術 - Hateburo: kazeburo hatenablog )

順調な前半

前半は事前の準備の効果があってめちゃくちゃスムーズにすすめることができた。はじめにやることのチェックリストを作ってあったので、あわてず丁寧にすすめることができた。

https://cdn-ak.f.st-hatena.com/images/fotolife/h/hakobe932/20160919/20160919124529.png

↑こういう感じ

  • 初期実装を起動してから最低限のnginxいれて、一度だけベンチをまわしてリクエストの傾向みる
  • CI、プロファイラを用意する
  • アプリケーションコードを呼んで怪しそうなところにあたりをつけておく

みたいなところを分担して一気にすすめて、一時間くらい。さらに一時間くらいデプロイできるようにしたり、コードを読み込むとかをしたところで、具体的な改善に入れそうだなとなった。

お昼頃にはリーダーボードにでてくるくらいのスコアになったので、ハイタッチして昼食休憩にはいったりした。

キャッシュの海に沈んだ後半

昼食をたべながら作戦会議をして、やはりhtmlifyを良くしていくのが良さそうだということで改善をはじめた。リクエストの傾向をみると表示に比べて更新の頻度が比較的低かったので、キャッシュが効くやろとかいって取り組みはじめた。このとき

  • htmlify された結果をキャッシュする
  • 正規表現の構築にRegexp::Assembleをつかう
  • 正規表現をキャッシュする

などを同時進行ですすめてたんだけども、これがあまり良くなかった。これらの変更を全部いれてベンチにかけたところめちゃくちゃFAILしまくる感じになってしまった。FAILの原因を丁寧につぶしていくという作戦にでたけど、2時間くらいはまってしまってだいぶ時間を無駄にしてしまった。

時間的な余裕もなくなったことで、新しいことをはじめる決断もできなくなってしまった。半分自棄になって、競技終了30分前にkeywordの文字数をカラムにいれてsortに使うようにする変更をいれたところ一気に15000点くらい点数があがって元気がでてきたものの、時すでに遅しであった。

反省

一つ一つの施策は方針が決まればすばやく実装できたのだけど、キャッシュまわりでうまくいかなくなり、打つ手がなくなったときにチームの活動がほぼ停止してしまい、うまくパフォーマンスをだせなくなってしまった。

全員が同じ方向を向いているパワーがでるけど、その方向をミスってしまったという感じがする。時間をきめてあきらめるとか、全員キャッシュに向かずに別のことをしてる人をつくるとかすると、もう少し安定感がでたかもしれない。

感想

せめて自分たちの考えたアイディアを全部うまく実施したかったけど、実現パワーが足りなくて、道半ばという感じで終わってしまいかなりくやしい。のらりくらりとコードを書いていてはいけない。来年あったら一矢報いたい。

初参加ということで、はじめてISUCONを体験したけども、これは運営大変だなと感じた。みんな真剣にやってるのでミスするとやばい感がすごい。運営のみなさま、本当にありがとうございました。

以下は会社の反省会の後での感想です。

アマチュア無線の専門店にいってみた

お休みをいただいて大阪で用事を済ませてきたのだけど、帰りに日本橋のアマチュア無線の専門店をのぞいてきた。のぞいたのは中野無線というところで、いかにも初心者ですという感じで店内をながめていたところ、気さくな店員さんがいろんな話を聞かせてくださり、かなり勉強になった。

144MHz帯や430MHz帯のFMはラグチュー中心になりつつあるらしくて、CQだして楽しみたいのであればHF帯がおすすめということのようであった。ただ、144MHz帯や430MHz帯であってもデジタル方式であればレピータ局などを経由して、日本中の人とつながれるので楽しむこともできるので、やりようはあるとのこと。

初級者向けのモービルの無線局+安定化電源+アンテナのセットだとどうしても10万円くらいのコースにはなるらしい。例えば予算が5万円ということであれば、中古品をやりくりすることもできるし、いろんなプランを用意できるので、相談してほしいとのこと。

アマチュア無線ガチ勢のお話なども伺ったがかなりおもしろく、アマチュア無線のために山に小屋をたてたりだとか、島に移住したりだとか、何百万円もするタワーアンテナ建てているだとか、いろんなエピソードがでてきた。だいたい現在進行形の話題なのがすごい。

勢いで10万円支払う勇気がなかったので、その場はお礼をいって帰ってきたのだけど、かなり頼りになるお店という感じで実際リグを買うときには相談したい。が我が家の電波状況はあまりかんばしくないのもわかってきたので、どういう方針でやってくかめっちゃなやむ〜。

RubyKaigi にちょっとだけお邪魔した

用事があって初日の懇親会と最終日の午後しか参加できなかったのだけど、たいへんおもしろかった。YAPCにはよくいってたけど、RubyKaigiに参加するのははじめて。

普段はあまりRuby界隈に顔は出さないので、ぼっちになるかと思いきや、意外と見知った方がたくさんいらっしゃった。大学時代はRuby関西のコミュニティにずいぶんお世話になったのだけれども、その界隈の方とは会うのはかなりひさびさに会えて話せたのも良かった。知り合いつながりで、はじめての方とも会話するのにも成功したので、なんとかなったと言えそう。みなさま、かまっていただきありがとうございました。

発表は数えるほどしか見れなかったものの、Rubyならではの言語の実装や開発の取り組み方の話題も聞けて新鮮だった。めっちゃCの話がでてくるなー。YAPCに比べると海外からの参加者がより多いような気もする。気がするだけかも。

でかい技術カンファレンスが電車一本でいける距離で開催されるのは不思議な感覚になる。これまでは自分の中では、だいたい旅行とセットという認識だった。

あまり積極的にかかわれなかったもの、なんやかんやで参加してよかったなー。

1アマ合格してた

先日、1アマを受験してきた記事を書きましたが無事合格できておりました。自己採点ではだいたい大丈夫そうということがわかってものの、ちゃんと合格って書いてある紙がやってくるとうれしい。

このあと実際に免許されるには、さらに申請が必要で、免許証が届くのは一ヶ月先とからしい。先は長い。