API Gateway + Lambdaでcatch allした処理をApex + Goでnet/httpで扱える ridge を書いた

タイトル長い。 LambdaでGoが正式サポートされるのを首を長くして待ちつつ、Apex で Go を実行しています。

先日、API Gatewayで受けたすべてのリクエストをLambdaに丸投げすることができるようになりました。

これまではAPI Gatewayでいちいちマッピング定義を作るのが面倒で、いまいち普通のWebAPI的なものをLambdaで作る気がしなかったわけですが、これで行けるのでは…? と思って、catch all されたリクエストとレスポンスを net/http.Request と net/http.ResponseWriter で扱えるようにする ridge というライブラリを書いてみました。

github.com

Readmeそのままですが、以下のような Go のコードが API Gateway (プロキシ統合)+ Lambda + Apex で動きます。

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "os"

    "github.com/apex/go-apex"
    "github.com/fujiwara/ridge"
)

var mux = http.NewServeMux()

func init() {
    mux.HandleFunc("/", handleRoot)
    mux.HandleFunc("/hello", handleHello)
}

func main() {
    if os.Getenv("APEX") == "" {
        // ローカルで動かしたい場合はこっち
        log.Println("starting up with local httpd")
        log.Fatal(http.ListenAndServe(":8080", mux))
    }
    // Lambdaで動く場合はこっち
    apex.HandleFunc(func(event json.RawMessage, ctx *apex.Context) (interface{}, error) {
        r, err := ridge.NewRequest(event)
        if err != nil {
            log.Println(err)
            return nil, err
        }
        w := ridge.NewResponseWriter()
        mux.ServeHTTP(w, r)
        return w.Response(), nil
    })
}

func handleHello(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    fmt.Fprintf(w, "Hello %s\n", r.FormValue("name"))
}

func handleRoot(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    fmt.Fprintln(w, "Hello World")
    fmt.Fprintln(w, r.URL)
}
  • 入力の JSON*net/http.Request に変換してアプリケーションに渡す
  • ridge.ResponseWriternet/http.ResponseWriter interfaceを持っているのでそれに対してレスポンスを書き込む

とすると、普通に Lambda で Go の webapp らしきものが動きます。

ユーザの書くコードは普通の Go の webapp と同様 func(http.ResponseWriter, *http.Request) で行けるので、ローカルでは http を直接 listen するサーバとして動かしつつ、API Gateway + Lambda でも同じコードを動かせる……これはもしかして凄く便利なのでは!

制限とか

  • URL引数に同名の値 (foo=1&foo=2 みたいなの) があると、入力Eventの時点でひとつになってしまう
  • HTTPリクエスト/レスポンスヘッダで複数同じものがあっても同様
  • バイナリの入出力ができるのかどうか良く分からない

という現時点の制約があります。ちゃんとバイナリが扱えれば、画像変換サーバみたいなものにも使えて夢が広がる感じなのですが…

ともあれ現時点でも、普通にHTMLやJSONを返すAPIを実装するのには使えるはずですので、是非お試しください。

ISUCON 6 予選通過しました

ISUCON 6 にチーム「morimoto組」で参加して、予選を通過して決勝進出することになりました。

ISUCONは過去5回のうち優勝3回、3位1回、出題1回、ということでもう引退(勝ち逃げ)しようかな…とも思ったのですが、今年は出題にも関わっていないので参加しないと完全に縁が切れてしまうし、それも寂しい。ということで。

チームメンバーは直前まで決まらなかったのですが、結局会社の新卒1,2年目( id:amusan , id:moshisora ) と組むことにしました。若いとはいえ去年と今年の社内ISUCON優勝メンバーです。(歳の差何歳だろう)

当日やったこと

天気は悪いが見晴らしはいい会議室を確保して万全の体制 (まぶしいのですぐブラインドは下ろされました)。

言語は Perl です。

  • インスタンス起動、事前に用意していたChefを実行して環境整備
  • isutar を isuda 内に取り込み
  • 正規表現の生成を Regexp::Trie に変更
    • 各プロセスで生成すると重いのと整合性を確保しづらいので、POST /(initialize|keyword) を処理するアプリケーションを1プロセスだけ起動するようにして分離。生成された正規表現を Redis に保存し、htmlify を処理するプロセスはその正規表現を使う
    • 1プロセスのみにしたので、keywordがpostされてきた順番に $trie->add($keyword) していくだけで整合性が維持できる
  • 静的ファイルは nginx で static_gzip、expires max を付与する
    • 304が返せるようになる

nginx.confはこんなかんじ。

 http {
    upstream app {
       server unix:/var/tmp/app.sock;
    }
    upstream app_post {
       server unix:/var/tmp/app_post.sock;
    }
    include /etc/nginx/mime.types;
    server {
        location ~ ^/(css|img|js|favicon\.ico) {
           gzip_static on;
           expires max;
           access_log off;
           root /home/isucon/webapp/public;
        }
        location /initialize {
            proxy_pass http://app_post;
        }
        location /keyword {
            set $app "app";
            if ($request_method = "POST") {
              set $app "app_post";
            }
            proxy_pass http://$app;
        }
        location / {
            proxy_pass http://app;
        }
  }
}

ここまでやった状態で14:40すぎに8万点ほどでトップに躍り出る。

ここで、アプリケーションのプロセスを再起動せずにベンチを回していくと、どんどんスコアが上がっていくという現象を確認。2回目だと12万点ぐらい。 特にメモリ内に cache は作っていない (つもりだった) ので、何が原因なのかさっぱり分からず。

ここから、他のチームがスコアを上げてきたのになかなか上げられず苦しむ時間帯。

  • / でoffsetが大きいクエリをentry using(id) の自己結合に
  • /stars を Resis にキャッシュ (get_multiで一気に取る)
  • uri_forを消す
  • user_nameもセッションに入れてクエリを消す
  • isupam は何とかできないかと考えたが結局手を入れられず

これでだいたい9万ぐらいだったので、このままだと予選通過はボーダー付近だった模様。

17:30ごろから2度目のベンチでスコアが上がる現象を解明するべく、個別にプロセスを再起動して切り分けしたところ、POSTを担当するプロセスを再起動しなければ速度が出る、ということを確認。こいつは Regexp::Trie のオブジェクトを永続化して持っているので、二回目は既に初回のベンチでキーワードが追加済みの状態になっていた (ので速かった)。

つまりこの状態では本来リンクになってはいないはずのキーワードがリンクになる状態。アプリケーションとしてはまずいんだけども、ベンチマーカーがそれを検出しても結果がPASSとされていればスコアも有効である、ということを運営とのやりとりで確認していたので、(多少良心が痛むものの) 突っ込むことに。

1回ベンチが走って追加された状態のキーワードをテキストファイルに書き出しておいて、initialize でそれを Regexp::Trie にaddしておくというコードを追加して、終了1分前にベンチqueue投入。18時の終了3秒前ぐらいにベンチが始まり、その状態で dstat をみていた限りでは14万点だしたときとおなじぐらい捌けてそう、というところで(最終的にスコアは知れずに) 競技終了。

結果、143,366で通過できました。

予選を終えて

チームメイト二人ともなぜか Perl-5.24 を手元で動かせずに、手元でコードの確認ができない状態だったのが完全に想定外 (環境構築で30分ぐらいハマってたので「もうそれは諦めて、こっちで動かすので」という判断を早めにできたのがよかった…)。それ以外は、結構ちゃんと戦えたのかな、という感想です。

聞くところによると、htmlfy()の結果cacheは結構雑でも (リンク関係を検出はされるものの) スコアが出せたようなので、ここがもっと厳密だったら展開も変わってきたのかなあ、という印象はあります。(とはいえ、一発アウトにするのは出題側も誤検知が怖いんですよね…)

幸いにも、これで ISUCON 本選は6年連続で出場できるので、精一杯戦いたいと思います。運営の皆様、楽しいイベントを本当にありがとうございます!

「みんなのGo言語」の執筆に参加しました

技術評論社から発行される「みんなのGo言語」という書籍の執筆に参加しました。本日、9月9日発売です!

gihyo.jp

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

Goと自分

Goは2009年に一番最初にリリースされたときにちょっと触っていて、このblogにもいくつかエントリを書いていました。 golang カテゴリーの記事一覧 - 酒日記 はてな支店

その後、実際にプロダクションで使うことがなかったのでしばらく離れていたのですが、 2013年頃からGoが盛り上がってるなという雰囲気もあり、

で、ここ数年はもっぱら Go をメインで書くようになっていました。公開している OSS としては

をはじめ、いろいろあります。Perlをメインで書いていたときも CPANに上げていたもの があるのですが、ほとんどがライブラリで、いわゆるアプリケーションは少数でした。

Goではライブラリよりもアプリケーションを多く公開するようになったのが面白いなと、今振り返って思います。これはGoが、デプロイのしやすいシングルバイナリで動作するアプリケーションを書くのに向いている、ということ無関係ではないでしょう。

執筆について

Go製の OSS をいくつか公開していたことからか suzuken (id:suzu_v) さん、id:mattn さん経由で声を掛けていただいて、共著で執筆することになりました。雑誌記事は WEB+DB PRESS に書いたことがあるのですが、書籍は初めての経験です。

自分がどういうことについて書けるかを考えた結果 (言語自体には特に詳しくもないですし)、Goでこれまで書いて、本番で運用してきた実用アプリケーションを作り上げることについてのTips的なことならば書けそう。ということで、本書では第3章の「実用的なアプリケーションを作るために」という内容で執筆させていただきました。

内容は本当にTips的で、最初に一通り書いたところではあまりに断片的すぎた感があったのですが、編集のかたや共著者のレビューでお力添えをいただいて、なんとかまとめることができました。

本書について

本書は、最初からGo自体の入門書ではなく応用のための実用書、という位置づけで書かれていて、どの章も現場でGoをつかって仕事をする人に役に立つ内容になっていると思います。A Tour of Go や プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES) で言語自体を学んだ上で、実際になにかまとまったものを書き始める時に、よいお供になると思います。144ページと気軽に読める分量で、お値段も1980円(本体)と比較的安価ですので、是非お手にとっていただければと思います。

最後に

connpass.com

リリースパーティーを開いていただけるそうで、自分もビールを美味しく飲みにお邪魔する予定です。まだ定員に余裕があるようなので、こちらも是非よろしくお願いします。

WEB+DB PRESS vol.94 特集「実践スケーラブルAWS」を執筆しました

機会をいただいて、技術評論社 WEB+DB PRESS vol.94 の特集1「実践スケーラブルAWS」を同僚の id:tkuchiki と執筆しました。本日8/24発売です。

WEB+DB PRESS Vol.94

WEB+DB PRESS Vol.94

どなたかが編集のかたに自分を推薦していただいたようで、インフラの特集で、というお話をいただいて、ここ数年はほぼAWSをメインで使っているのでAWS前提の内容でよければ…ということで寄稿することになりました。

[鍵は監視にあり!]実践スケーラブルAWS

  • 第1章:AWSにおけるスケーリングの基本戦略
    • 成長段階に合わせた適切なインフラ構成……藤原 俊一郎
  • 第2章:規模が拡大しても破綻しない監視
    • 監視対象を動的に増減,値を集約して適切に通知……藤原 俊一郎
  • 第3章:Webサーバ/アプリケーションサーバのスケール
    • ELBでロードバランシング,SQSで非同期処理……朽木 拓
  • 第4章:キャッシュサーバのスケール
    • ElastiCacheとtwemproxyを組み合わせ負荷を分散……朽木 拓
  • 第5章:データベースサーバのスケール
    • RDSでリードレプリカを利用,フェイルオーバーへの対応……朽木 拓
  • 第6章:オートスケールを無駄なく活用
    • 自律的なプロビジョニング,余裕を持った発動ポリシー……藤原 俊一郎

1,2,6章を自分が、3,4,5章を id:tkuchiki で分担しています。

内容は、1台からはじめた小規模なサービスを AWS で100台規模までスケールさせて行くにはどうすればいいのか、という想定で、それに必要な要素や構築の際に注意すべき事をまとめてあります。

最近はクラウドで「スケーラブル」というとコンテナやサーバーレスやら、というかっこいい話になりそうなものですがそうではなく(そもそもそこまで仕事で突っ込んでないので)、普通にEC2上にアプリケーションサーバを立てるような構成でどう徐々に拡張していけばいいのか、という、どちらかというと泥臭い話です。

全体を貫く軸としては「監視」をメインにしていて、どのような項目をモニタリングして判断すればいいのか、という指針で各章に記述があるのと、監視だけで独立して章を設けてZabbixとMackerel、ログ集約(分量は少ないですが…)には Fluentd と Norikra などを取り上げています。

また、AWSらしいところということでオートスケールについても章を設けました。これは先日 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa で発表した内容がベースになっていたりします。

他の特集も Kotlin、Electron と今話題の技術が取り上げられていて大変面白いと思いますので、是非お買い求めください!

Fluent::Logger(Perl)をFluentd 0.14のSub-second timeに対応した

Fluentd 0.14 がリリースされましたね。

Fluentd v0.14.0 has been released | Fluentd

新機能が盛りだくさんですが、そのうちの一つ Sub-second time (秒未満の解像度のtimestamp) に Fluent::Logger 0.18で対応しました。

<source>
  type forward
</source>

<match **>
  @type file
  path  ./test
  time_format %Y-%m-%dT%H:%M:%S.%N
</match>

このような fluentd.conf で fluentd 0.14 で起動して、以下のように event_time オプションを真にした Fluent::Logger から送信すると、

#!/usr/bin/env perl
use 5.12.0;
use Fluent::Logger;
use Time::HiRes;
my $logger = Fluent::Logger->new( event_time => 1 );
$logger->post(
    test => { foo => "bar" },
);
$logger->post_with_time(
    test => { foo => "baz" },
    1464845619.12345, # floatで指定
);

以下のように秒以下の精度を持った時刻でログを送信できます。

2016-06-02T14:40:52.251250982    test    {"foo":"bar"}
2016-06-02T14:33:39.123450040    test    {"foo":"baz"}

Perl側のinterfaceは浮動小数点数なので、正確にはnanosecond単位の精度はありません。もし精度が必要なら、floatではない値で指定できるような方法を検討するのでお知らせください。時刻指定なしの post() では内部で Time::HiRes::time() を呼び出してその時刻を送信しています。

ちなみに送信先が fluentd 0.12 の場合に event_time => 1 で送信するとエラーが発生しますのでご注意ください。(クラッシュはしないようですが)

[error]: forward error error=#<MessagePack::MalformedFormatError: invalid byte>
error_class=MessagePack::MalformedFormatError

Enjoy!

#shibuyago #2 で Stretcher の実装について話した

Shibuya.go#2 という勉強会で、自分が開発している Pull型デプロイツール Stretcher について発表してきました。 shibuyago.connpass.com

発表資料はこちらです。 speakerdeck.com

Goの勉強会なので、Stretcherの実装で使われているTips的なコードの紹介を多めにしてみました。

ちなみに資料中で紹介している copyAndCalcHash の実装は、既にPRをいただいて io.MultiWriter によってすっきりきれいになっています。

copyAndCalcHash is simplified by io.MultiWriter by shogo82148 · Pull Request #13 · fujiwara/stretcher · GitHub

会場とピザ、ビールを提供していただいた VOYAGE GROUP 様、主催の @suzu_v 様、ありがとうございました!

nginx実践入門

「nginx実践入門」 を著者の @cubicdaiya さんからいただきました。ありがとうございます。 簡単ですが感想など。

nginx実践入門 (WEB+DB PRESS plus)

nginx実践入門 (WEB+DB PRESS plus)

感想

一通り読んだ感想としては、本書は「『実践』入門」であっていわゆる入門書ではないのですね。 手取り足取りしてくれるわけではなく、リファレンスの詳解でもなく、あくまで実践的に運用する人へ向けての、実用的な使い方の入り口を紹介してくれる本でした。

特に最近重要性の高い TLS(SSL) での安全でハイパフォーマンスな設定、大規模コンテンツ配信サーバの構築を例とした多段 proxy 構成、実用的なログ出力と Fluentd によるメトリクスモニタリングなど、本番環境でサービスを運用するために役立つ情報が多く載っています。

今時は Web サーバの運用は単体で完結するものではなく、モニタリングや周辺システムとの連動が必須になってきているという事情を踏まえての構成だと感じました。

また、ngx_lua, OpenResty についての情報は、日本語書籍ではほぼ初めての登場になるかと思います。Lua はうまく使うと nginx 単体ではトリッキーな設定になるようなものも分かりやすくなるので、ありがたいですね。

気になったところ

6章でアプリケーションにクライアントの IP アドレスを伝達するために、

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

アプリケーションはX-Forwarded-Forヘッダの最も初めに存在するアドレスを使用することでユーザの送信元アドレスを把握できます。 (140ページ)

という部分があるのですが、この設定では nginx はクライアントが X-Forwarded-For ヘッダを付けてリクエストした場合、クライアントの IP アドレスを「追加」してアプリケーションに渡す形になります。

$ curl http://127.0.0.1/
→ X-Forwarded-For: 127.0.0.1

$ curl -H 'X-Forwarded-For: 192.168.1.1' http://127.0.0.1/
→ X-Forwarded-For: 192.168.1.1, 127.0.0.1

そのため、アプリケーションが先頭のアドレスを見た場合、その値は信用できないため、アクセス制限を回避されてしまう可能性がありそうです。

realip_module を使用して nginx が $remote_addr を偽装できない形で識別した上でアプリケーションに渡すか、

real_ip_header X-Forwarded-For;
real_ip_from [信頼できる接続元(多段proxyの親、ELBなど)のアドレス範囲];
proxy_set_header X-Forwarded-For $remote_addr;

アプリケーション側では X-Forwarded-For ヘッダの先頭ではなく末尾 (N段構成の場合は末尾からN番目) のものを見る必要があるかと思います。(基本的には最後の値は直接通信しているnginxが付けているので安全)

最後に

出版記念のイベントで LT をさせていただくことになりました。カヤック(の Lobi というサービス) で nginx + Lua (openresty) をどう活用しているかをお話しする予定です。

eventdots.jp