JSとかCSS、画像などの静的ファイルはS3に向けて、それ以外はアプリケーションサーバーにルーティングしたいというよくあるケース。CloudFrontとかFastlyではよくやるパターンなのでCloudflareでもサクっとできるだろう思ってたけど意外と難しかったのでメモっておく。まず前提として、Cloudflareではパスベースのルーティングがエンタープライズプランでしか使えない。https://support.cloudflare.com/hc/en-us/articles/206190798-Using-Resolve-Override-in-Page-Rulesなので、ex...

Cloudflareで静的アセットをS3 Originで配布したい

最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。https://laiso.hatenablog.com/entry/nope-sqlhttps://k0kubun.hatenablog.com/entry/surplushttps://sue445.hatenablog.com/entry/2022/05/06/170001前提としてはこんな感じ。仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない技術スタックは技術的な実験とか学...

個人開発のサービスをVPSからVercelとCloud Runに移行した話

生活去年の12月に東京から福岡に引っ越したので、今年は福岡での生活に慣れる年になった。引っ越す前までもほとんどリモートで仕事していたので、仕事に関してはそうでもなかったけど、子ども関連が大変だった。新しい保育園のあれこれを準備したり、送迎フローを確立したり、休日の遊び場所を探したり。今はもうだいぶ慣れたので子ども関連は引っ越す前と同じぐらいの労力になった気がする。それとこれまではオフィスで仕事したり家で仕事したりで環境が変わるのが嫌でMacBook一台で開発することにこだわっていたけど、基本家でしか仕事しなくなるということで外付けのディスプレイとかキーボードを買って仕事環境を整えた。ウルトラワイドのディスプレイが便利すぎてもう元の生活には戻れなくなったね。ただ、引っ越してから緊急事態宣言やらなんやらでほとんど外に食べに行くことができなくて期待していた福岡のおいしいご飯はまだあまり体験できていない。そのへんのスーパーで売ってるお刺身が普通においしかったりするのは嬉しいけど、モツ鍋とか水炊きとか屋台とかもっといきたかったね。とはいえ10月くらいからは徐々に行けるようになったのでこれまでの分を取り返しにいっている。これは記憶の中では一番おいしかった中洲の屋台の焼きラーメンだけどけっこう飲んでる状態で食べたのでお店の名前もわからないけどもう一回食べたい。総じて福岡はいいところなので引っ越して良かったと思っている。何よりも家が家賃半分以下で倍以上広くなったのがいい。仕事今年の前半はクックパッドでレシピサイトのフロントエンドのNext.js移行を引き続きやっていたり、春インターンでNext.jsの講座をやってYouTuberデビューしたり、夏インターンで講師業をしたりしていた。その後なんやかんやあって9月にUbieに転職したのが一番大きい出来事だった。Ubieでは主にユビーAI問診とかユビーAI受診相談のプロダクト開発をやっていた。技術的にはGCPとかKotlin、Spring Bootが初体験で新しいことを学ぶのは楽しいと同時に、学びながら開発するのはスピードがでなくてつらいなという気持ちも味わった。プロダクト開発の傍ら、開発環境のセットアップとか日常の開発環境のメンテナンスみたいなものに課題を感じて開発体験を最大化するチームに入ってそのあたりの改善でM1 Macで開発できるようにしたりしていた。本当はもう少しこのあたりをやりたいんだけど、来年は紆余曲折あってレガシーRailsの発破解体をやることにした。前職でも同じことをやるチームをリードしていたので、クソッ何回転生してもレガシーRailsをやることになっちまう、という感じだが好きでやっているのでやっていくぞという気持ち。それとアクセシビリティのチームに入ってeslint-plugin-jsx-a11yを導入したりUDフォント導入の実装をしたりもした。入社して4ヶ月しか立ってないけど振り返ると意外と色々やっとるな、という感じがする。Ubieはみんなやる気に溢れていて仕事していて楽しいし、医療ドメインも開発も面白いので来年も色々やっていくぞ。興味ある人は遠慮なく声かけてね。登壇とかイベントとか個人開発とかKaigi on Rails というイベントに登壇したり、JSConf JP に Ubie でスポンサーとして参加してブースに立ったりした。どちらのイベントも SpatialChat とか reBako を使ってブースや懇親会がおこなわれていて、以前オフラインでカンファレンスに参加していたころの体験に近いものを得られてとてもよかった。個人開発はほとんどやっていないけど、クックパッド時代の同僚が僕が作っているBdashというSQLクライアントのサーバー実装であるBdash Serverというのを作ったのでそれの機能開発を少しやったりしていた。あとはAdventarにサイボウズさんから協賛いただいて初めてAdventarがお金を生んでうれしかった。サイボウズ様からAdventarに協賛・寄付をいただきました。ありがとうございます。今後もよりよいサービスを継続して運営できるようにがんばります！  https://t.co/EFbrrYChdB— Adventar (@adventar) 2021年12月20日  まとめ今年は福岡での生活に慣れるのと転職のあれこれであっという間に過ぎ去ってしまった。個人開発とかアウトプットはほとんどできなかったけど仕事にも生活にもだいぶ慣れたので来年はブーストかけてやっていきたいね。

2021年の振り返り

RailsエンジニアのためのNext.js入門

昨日がクックパッド最終出社日で今日からヘルステックスタートアップの Ubie Discovery*1 で仕事します。クックパッドは2015年4月に入社したので6年半弱在籍しました。過去最長記録です。思えば色々なことをやりました。新規サービスの立ち上げをやったり機械学習を使ったサービスを作ったり、人事と兼任してエンジニア採用とか新卒採用の夏インターンとか TechConf の運営をやったり、技術基盤のグループに移ってマイクロサービス化をやったりフロントエンドの Next.js 化をやったり。クックパッドのサービスは好きだし、やりたいと思ったことに挑戦させてくれるし、同僚は優秀だしで特に大きい不満はなく、辞めるつもりはなかったんですけど、クックパッドで同僚だった人が何人か Ubie Discovery に転職してめちゃくちゃ楽しそうに仕事してるのを横目で見たのをきっかけに興味を持ち、話を聞いてみたら事業内容とか組織の体制とかに惹かれて転職を決めるに至りました。これまでも他社の話を聞きに行ったり、体験入社に行ってみたりもしていたけど、選考に乗ってみようと思ったのは Ubie Discovery が初めてでした。一番大きい理由は医療というビジネス領域です。僕は元々自分とか自分のまわりの人の生活が便利になるようなものを作りたいと思っていて、それがクックパッドに長年いた理由のひとつでもありますが、子どもが生まれて病院にお世話になる機会が増え、さらにはコロナ禍によって自分や家族の健康について以前よりも考えることが増えてきました。そういった中で Ubie Discovery が解決したい課題やビジネス戦略などの話を聞き、この課題が解決されれば自分や家族にとってより良い社会になるだろうということが想像でき、自分でもその課題を解決したいと強く思うようになりました。それと人事評価をなくしたり、ホラクラシーという組織運営の方法など、これまで在籍したことがある会社とは一風変わった制度の話も色々聞いて興味を惹かれました。単に人事評価をなくしたりフラットな組織にしました、という話ではなくそれを継続するための仕組みづくりや組織づくりに興味を惹かれ、この会社で働いてみたいと思うようになりました。このあたりの話についてはクックパッド時代にも同僚だった @h13i32maru が詳しく書いているので興味がある人はこちらを見てください。最後にもうひとつがストックオプションです。人生一回ぐらいはスタートアップで一発当ててドーンというのを体験してみたいなあとぼんやり思ってはいましたが、幸いなことに選考も通り、夢を見るには十分なストックオプションと現職と同程度の年俸を提示していただきました。ただ、考えてみるとお金はもちろんほしいけど僕が真にほしいのは夢を追いかける過程で熱くなれる気持ちなんじゃないかと思っています。それも自分ひとりだけではなく、同じように夢を実現するために熱くなる仲間と一緒に熱くなりたい。そう、青春なんですよ。僕がほしかったのは青春。とりもどせ青春。Ubie Discovery では同じような思いや熱意を持った人がたくさんいて、事業のフェーズ的にもちょうど伸びてきているところで、ここでなら青春を謳歌できるに違いないと思い入社を決意するに至りました。積極採用中Ubie Discovery 最近めっちゃエンジニア入ってない？と思う人も思わない人もいるかもしれませんが、実はソフトウェアエンジニアという職種においてはまだ20人いないぐらいなので人が全然足りてません。そういうわけで Ubie Discovery に興味を持っていただいた方はお気軽に @hokaccha まで DM でご連絡ください！*1:Ubie 株式会社は 0 → 10の開発をおこなう Ubie Discovery と 10 → 100 のグロース&スケールをおこなう Ubie Customer Science に組織が別れており、自分を含め現状ではエンジニアは全員 Ubie Discovery に所属しています。

クックパッドを退職して Ubie Discovery に転職しました

TypeScript version: v4.3.5元々やりたかったのは以下のようなこと。外部入力の文字列を Union Type にマッチするか検証してマッチしなければデフォルト値を返すみたいなやつ。const colors = ["red", "blue", "yellow"] as const;type Color = typeof colors[number];const defaultColor = colors[0];function toColor(color: string): Color {  return colors.includes(color) ?...

TypeScript で値が Union Type にマッチするかを検証したい

https://github.com/hokaccha/electron-template-2021作ったので公開しておくが、こういうテンプレートはメンテしないとすぐ腐ってしまうけどメンテするモチベーションも特にないのでスナップショットという意味合いも込めて2021をつけている。 electron-nextベースに electron-next というのを使っていて、これがけっこうよくできていた。やっていることはシンプルで、レンダラプロセスに Next.js を使っていて、開発時は Next.js のサーバーを起動し、production build では next export ...

Electron アプリのテンプレート 2021

最近は ECMAScript 自身の機能も豊富になってきて lodash のユーティリティ関数の出番はだいぶ少なってきたけど、debounce と throttle だけは未だに使う機会がまあまあある。しかし、lodash は何も考えずに使うとバンドルサイズが肥大化するのでいい感じに Tree Shaking するために lodash-es を使う必用があったり、自分が使っている機能とは全然関係ないアップデートが Dependabot から大量に降ってきたりしてしんどかったりする。lodash は lodash.debounce のように個別のモジュールも提供されているけど、Last Published が 5 years ago になっていたりして、あまり継続的にメンテされてない様子が伺える。これに関する Issue は探すといっぱいあって、対応したいけど手が回ってないみたいな様子らしい。debounce とか throttle は lodash 固有のものではないので探せばいっぱい実装は見つかるんだけど、微妙に API が違って使いにくかったりして lodash 互換でついでにビルトインで TypeScript の型も提供してほしいし、ということで debounce と throttle だけを切り出したモジュールを作った。処理を間引くので mabiki。実装はほとんど lodash から持ってきて TypeScript 化してテストを通るようにしたぐらい。ESM と CJS 両方対応していて TypeScript の型も提供しているのでたぶん便利。

lodash 互換の debounce と throttle だけを提供するライブラリを作った

const obj: any = { a: 1, b: "x" };function foo<T, U>(x: U): [T, U] {  return [obj[x], x];}こういうコードがあったとする。コードの良し悪しは置いといて、U は引数から推論して、T は呼び出す側から指定したいというケース。// こう書きたいけどエラーfoo<number>("a"); // Expected 2 type arguments, but got 1// これは通るfoo<number, string>("a");これは今現在（TypeScript 4.0）ではできないみたいで、Proposal があがっていた。https://github.com/microsoft/TypeScript/issues/26242ワークアラウンドな方法を見つけたけどこれを使うぐらいなら素直に型引数書いたほうがよさそう。https://medium.com/@nandiinbao/partial-type-argument-inference-in-typescript-and-workarounds-for-it-d7c772788b2e

TypeScript でジェネリクスの部分的な型推論ができない

メリークリスマス！Adventarを支える技術 Advent Calendar 2019 の25日目、最終日です。最終日は今後の Adventar をどうしていきたいかについて技術編と機能編に分けて書こうと思います。技術編細かく直したいところはいっぱいありますが、大きめトピックだけいくつか書きます。SSR のキャッシュを入れたいSSR のキャッシュについては19日目の記事に詳しく書きました。今は毎回 Lambda を呼び出してレンダリングしているので、キャッシュすることでパフォーマンスをあげたいと思っていますが、コスト（お金）がかかる問題をどうにかしないと...。gRPC-Web の Node.js 対応5日目の記事に書きましたが、今 Node.js では gRPC-Web が使えないので SSR の際に仕方なく JSON API を使っていますが、完全に無駄なので gRPC-Web を Node.js でも使えるようにして同一コードでサーバー/クライアント両方動くようにしたいですね。そのためには gRPC-Web の ptoroc プラグインに手をいれないといけなくて、C++ を書く必要がありそうです。できるのかな。gRPC サーバーを Lambda で動かしてみるgRPC サーバーを Lambda と API Gateway で動かすのは、たぶんやればできるんじゃないかなと思ってますが、確証はないです。これができると ECS などのサーバーが不要になり、真のサーバーレスにできます。真のサーバーレスになると圧倒的にコスト削減できるはずなので、取り組んで見る価値はあると思います。GitHub Actions で CI/CD したい今はテストは手元で実行するだけになっているし、デプロイも手元からやっているという、プロとして恥ずべき状態です。CircleCI とかでもいいんですが、GitHub Actions ちゃんと使ったことないのでやってみたい。まあこのぐらいですね。どれも実際にやるかどうかはわかりません。機能編サービスをシンプルに保ちたいので、そんなにたくさん機能を追加するつもりはないのですが、現状でいくつかやりたいことはあります。探しやすくする今カレンダーを探すのはテキスト検索ぐらいしかないので、もう少しカレンダーを探しやすくするような機能をいれたいです。具体的にはカテゴライズ、スターを導入して人気順、募集中のものだけ検索、などを考えています。ちなみにカテゴライズについては過去のカレンダーを手動でカテゴライズしてみたのですが、ジャンルが幅広すぎて、あってもなくてもあんまり変わらないのでは、という気になったので一回置きました。機械学習でいい感じにカテゴライズできたりするかな。アイコン更新できない問題地味な問題ではあるんですが、今年一番お問い合わせが多かった問題です。詳しくは8日目の記事に書きましたが、Firebase Authentication の仕様の問題で、Twitter などのアイコンを更新した際に Adventar 側のアイコンが更新されるタイミングが難しい感じになっています。地味なんですけど、アイコン大事なのでどうにかしたいですね。iOS/Android のアプリどちらかというと技術的な興味によるものです。Web よりもいい体験が提供できるんだろうか。ちょっとやってみないとわかりません。ちなみに技術的には、Swift や Kotlin を学ぶために、それらの言語で作ってもいいし、React Native で作って、Web を React Native for Web で作り変えてみるなんていうのも技術的には面白そうではあります。以上です。もし機能要望などがあれば Twitter や GitHub にお気軽に書いてください。GitHub の Issue は日本語でも大丈夫です。まとめ書ききりました。がんばった。全部の記事を読んでくれた方、一部の記事を読んでくれた方、Adventar を使ってくれた方、ありがとうございました。今年はもう疲れたので何もしませんが、来年以降またがんばろうと思いますので、今後も Adventar をよろしくお願いします！それでは良いお年を！

今後のAdventar

Adventarを支える技術 Advent Calendar 2019 の24日目です。今日はこれまで Adventar が利用してきた技術がどのように変わってきたのかを書こうと思います。2012年リリースした年です。最初は Ruby と Rails を勉強したいと思い、何かいいサービスの題材はないかなあと思っていて、当時主に ATND で行われていた Advent Calendar が使い勝手が悪すぎて、Advent Calendar 専用のサービスを作ったら使いやすいんじゃないか、というので作りはじめました。（これは ATND が悪いわけではなくて、そもそも ATND はそういう目的のサービスではなかったというだけです）なので初期実装は Rails でした。サーバーは、たしか YAPC Asia か何かで、当時ペパボに勤めていた刺身さんから、Sqale というペパボのホスティングサービス（Heroku みたいなやつ）のクーポンをもらったのがきっかけで Sqale を使ってホスティングしていました。値段も安かったし簡単だったんですごくよかったんですけど、今はもう終了しちゃってます。ちなみに Internet Archive で見つけてきた当時の様子はこんな感じでした。やる気がなさすぎるｗ2013年ほぼ一人でやっていたところに、june29、ayumikoという強力な仲間を得て、飛躍的に完成度が高まった年です。june29 さんには僕の初心者 Rails コードをバシバシレビューしてもらい、ayumiko さんにはクソダサかった見た目を見違えるようなデザインにしてもらいました。また、この年からサーバーは Heroku に移りました。明確な理由はよく覚えてないけど、june29 さんが Heroku に慣れていた、Redis とか memcached などのミドルウェアが Sqale で利用できなかった（ような気がする）あたりが理由だった気がします。それとフロントエンドは Backbone.js を利用するようになったようです。当時流行ってたんですよ。当時のデザインはこんな感じだったみたいです。たしか12月になったらカレンダー一覧でなく記事一覧をトップに出したりしてました。背景の画像がなんかかっこいいですね。2014年この年は軽微な変更で、特に大きい変更や技術的チャレンジはないみたいでした。あんまり覚えてない。2015年Qiita にエントリを書いてました。https://qiita.com/hokaccha/items/c5cd96c2ec002e27ff4bサーバーは相変わらず Heroku だけど、フロントエンドを React で書き換えて、react-rails を使った Server Side Rendering を導入しました。当時 React がちょうど流行りはじめぐらいで、試してみたいなーと思っていたので投入してみた。当時まだ hypernova とかもなくて、Server Side Rendering の知見はほぼない状態だったので色々と苦戦した覚えがあります。react-rails は Turbolinks とまあまあ相性がよくて、Turbolinks の遷移時のイベントで React Component を Mount/Unmount できるし、初期描画のときだけ SSR、Turbolinks 遷移のときは CSR というふうにできて、ルーティングをクライアント側でやらずに Rails に乗っかれるし、アーキテクチャとしては今でも悪くない気がしてます。流行りはしないと思うけど。詳しくは前に発表したときの資料がありました。https://speakerdeck.com/hokaccha/react-rails-12016年軽微な変更のみで大きな変更はなかったみたいです。2017年この年は ECS にしてみました。今年はHerokuからAWSに移してDocker/ECSにしてhttpsになったりHTTP/2に対応したりしました。— hokaccha (@hokaccha) 2017年10月25日当時仕事でも ECS を使い始めていて、基盤チームが色々整備してくれていたのだけど、自分では何もわからなかったので一回 ECS でインフラを作ってみたかったというのが動機です。とにかく難しくて大変だった記憶があります。まあもちろん今年のほうが大変だけど。2018年ECS にして毎月1万円ぐらいかかることが判明して、ECS だいたい理解したし、できるだけ安価に運用したいということで雑な VPS に移して月1000円ぐらいで運用できるようにしました。itamaeで構成管理したり、 Mackerel を使い始めたりしました。あとなぜかタイムスリップして古きよき Capistrano によるデプロイになりました。Heroku に戻らなかった理由は覚えてないけど、なんでだっけな...。単純に VPS のほうが安かったからかな。2019年とにかくモダンな構成にしたいと思ってがんばって作り直しました。Adventar、長年 Rails だったシステムを、GoでgRPCのAPIサーバー、Nuxt.jsでSPAのフロントエンド、grpc-web、Firebase Authentication, Lambdaでサーバーサイドレンダリング、Serverless Framework などを使って刷新してオープンソースにした https://t.co/Te0buXpA3j— hokaccha (@hokaccha) 2019年10月31日オーバーテクノロジーすぎてすでに Rails に戻りたい— hokaccha (@hokaccha) 2019年10月31日来年には Heroku に戻ってるかも知れないです。まとめAdventar ができてからの歴史を振り返ってみました。2013年に基本的なかたちができてか大きい機能や見た目の変更はなく、個人サービスなので技術的なチャレンジを色々とやってみる実験台みたいになってます。今後も大幅な機能変更とかの予定はないけど、できるだけ使いやすくはしたいし、長くサービスを継続できるようにがんばりたいし、技術的チャレンジももっとやっていきたいと思います。明日はいよいよ最終日です。今後のAdventarの技術的チャレンジや方向性について書こうと思います。

Adventar の技術変革の歴史

Adventarを支える技術 Advent Calendar 2019 の23日目です。今年から Adventar はオープンソースにしました。ツールやライブラリ、言語などのソフトウェアであれば今の時代オープンソースというのは山程ありますが、サービスがオープンソースというのはそんなに多くないと思うので今回はそうした理由や、いい点、悪い点などについて書こうと思います。オープンソースにする理由特にクローズドである意味もないので、オープンソースにしたいとは前々から思っていて、昔のコードはオープンにしづらい履歴もあるし、システムリニューアルのタイミングでちょうどいいので、このタイミングでオープンにしました。オープンソースにして誰かの役に立てば嬉しいし、誰かが勝手にバグを直したり機能改善をしてくれるかもしれないし、Fastly や AWS などはオープンソース支援で料金を補助してくれたりするし（試しに申請してみる予定）、いいことばっかりです。https://docs.fastly.com/en/guides/accounts-and-pricing-plans#free-open-source-developer-accountshttps://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/ちなみにすでに実際に何件か Pull Request を頂いて、オープンにしてよかったと思えました。ありがとうございます。https://github.com/adventar/adventar/pulls?q=is%3Apr+is%3Aclosed（自分は master 直 push マンなのがバレる）また、オープンにすることであまり雑にできない、という緊張が生まれるのは良いですね。実際コードを読んでる人はほとんどいないでしょうが、見られる可能性がある、誰かの参考にされる可能性がある、というだけで、ちゃんと書かないと、という意識になります。と、書いてて思ったけどこれってサービスに限らず普通の OSS でも同じですね。ちなみに緊張感があるといいつつ、実際時間がなくて（いいわけ） Go のコードとかはけっこうひどい感じではあります。懸念点セキュリティ少し大変なのは、オープンになることでセキュリティリスクが高まることかなと思います。ただ、世の中のはオープンソースのソフトウェアで溢れていて、それに対して脆弱性もばんばんでているわけで、アプリケーションのコードだけ隠しても劇的にセキュリティが強固になるとは思いません。もちろんオープンよりはクローズドのほうがセキュリティリスクは減ると思いますが。また、クローズドだと雑にリポジトリ内に入れられるような情報を、オープンだと入れられない（ので環境変数などにする）、みたいなのは多少ありますが、より健全になるだけなのでこれについてはオープンのほうがいいですね。ただ、terraform のコードをオープンにするかはけっこう迷いました。ネットワークまわりの設定を間違えていたりすると危険だし、あまり外に出したくない情報ではあります。が、そういう理由もあり terraform でのインフラ構成はどは特に外には出さないので、こういうものこそ誰かの参考になれば、という気持ちでオープンにしました。危険な設定を見つけたらこっそり教えてください。サービスを真似される危険オープンソースにしたときに聞かれたことがあったので一応書いておきます。営利目的だと話は違いますが、Adventar を真似て作られたところで痛くないし、むしろ Adventar より使われるようなサービスになった喜んで Adventar を閉じます。他には雑なスパムみたいなコピーサービスが増えるみたい可能性もありますが、それは別にクローズドでも見た目を真似ることはできるし、結局コンテンツがないと意味がないので心配してません。ちなみに、サービスのコードをオープンにしているところはいくつかあって、有名どころだと dev.to や gitlab などがそうです。https://github.com/thepracticaldev/dev.tohttps://gitlab.com/gitlab-org/gitlabこれらのサイトはオープンですが特にそれを使って類似サービスがでたりはしてないし、心配するだけ無駄だと思っています。まとめ今日はサービスをオープンソースにして開発する意味や懸念点について書きました。明日は Adventar の歴史について書こうと思います。

サービスをオープンソースにする

Adventarを支える技術 Advent Calendar 2019 の22日目です。さすがにネタ切れ気味なので、UI 系の細かいネタを投下します。ユーザーアイコンが404のときにフォールバックAdventar では Twitter などのソーシャルログインを使っていて、ユーザーのアイコンは各プロバイダから取得できる画像の URL をそのまま使っています。その URL がずっと使えるならいいのですが、ユーザーがプロバイダのほうでアイコンを更新した場合などに古いアイコンの URL がリンク切れになってしまいます。そうなると、ひどいと以下のようなってしまいます。これはひどい。せめてデフォルトアイコンを設定するようにしたいところです。しかし、アイコンの URL はアクセスしてみないと取得できるのかどうかわかりません。そこで img 要素の onerror イベントをトリガーしてデフォルト画像にフォールバックしています。<img src={{user.icon}} onerror="this.src = '/default.png'">実際は Vue.js でやっていてもう少し複雑ですが、こんな感じのイメージです。実際のコードは以下です。https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/frontend/components/UserIcon.vueこれでさっきの画面は以下のようになります。だいぶマシですね。部分的にローディングAPI の呼び出し待ちなどにローディングを表示するのはユーザーに状況を伝えるのに重要なアクションですが、ローディングを表示するのはできるだけ小さい範囲に留めるようにしています。例えばトップや検索画面のカレンダー一覧ですが、カレンダーの一覧取得には API の結果を待たないといけないので、返ってくるまでしばらくラグが発生します。そのとき全画面ローディングにしてもいいのですが、以下のように、必要な部分だけをローディングにすることで、可能な限りユーザーに速く画面を見せます。また、8日目の記事に書いたのですが、最初のログイン処理にやや時間がかかってしまうため、その間ローディングを出したいのですが、これもログイン情報が必要なところは多くないので、必要なところだけローディングにして体験を損ねないようにしています。これでだいぶ初期表示が速くなり、体験がよくなります。吹き出しの位置のこだわりこれは本当に細かいのですが、カレンダーで登録情報を編集するポップアップがあるのですが、この吹き出しの位置に微妙なこだわりがあって、端の登録を押したとき、スマホなどの画面幅が狭い場合は以下のようになります。可能な限り選択した吹き出しに近い位置に出して、吹き出しの三角は選択したセルを指します。また、PC などの画面幅が広いデバイスで見た場合は左右に余白ができるので、端のセルでも中央にポップアップを表示したいところです。書いてみると当たり前の動きな動きすぎてなんでこれを紹介しているのか自分でもよくわからなくなってきましたが、この動作をあらゆる画面幅で動作するように実装するのが思いの他大変だったので紹介したくなっただけです。実装を見返してみると色々ハードコーディングしてあったりして泥臭くてだいぶひどい感じですが、がんばった後が見られますね...。https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/frontend/components/CalendarTable.vue#L188-L212まとめ今日はネタ切れ気味で細かい UI の話を書きました。本当に細かすぎてすいません。明日は Adventar をオープンソースで公開した話を書こうと思います。

細かすぎて伝わらない UI の工夫

Adventarを支える技術 Advent Calendar 2019 の21日目です。このご時世には信じがたい話ですが、去年まで Adventar はスマホで見ると PC View を縮小するだけで、スマホでは非常に使いづらいサービスでした。今年のシステムリニューアルでは機能追加したりや見た目を変える余裕はなかったのですが、さすがに恥ずかしい、アクセスも iOS が一番多いという言い訳のできない証拠があったので、モバイル対応だけはやることにしました。レスポンシブと出し分けモバイル対応（というかマルチデバイス対応）は、大きく分けて2つの手法があって、HTML は同一で、画面の大きさによって CSS を変更することで対応するレスポンシブ（Webデザイン）と言われる手法、ユーザーエージェントなどの情報を元に、スマホ用や PC 用などの HTML を出し分ける方法があります。機能やレイアウトがガラっと変わるのであれば出し分けのほうがよいですが、スタイルの変更だけで要件がまかなえるのであればレスポンシブのほうが楽な場合が多いです。個人的には、スマホで見たときと PC で見たときにコンテンツの位置が全然違ったり、PC にあった機能がスマホだとなくなっているという体験が嫌いなので、今回はレスポンシブで対応しました。ブレイクポイントを決めるブレイクポイントは感覚がよくわからないので Twitter Bootstrap を参考にしました。https://getbootstrap.com/docs/4.3/layout/overview/#responsive-breakpoints// Extra small devices (portrait phones, less than 576px)// No media query for `xs` since this is the default in Bootstrap// Small devices (landscape phones, 576px and up)@media (min-width: 576px) { ... }// Medium devices (tablets, 768px and up)@media (min-width: 768px) { ... }// Large devices (desktops, 992px and up)@media (min-width: 992px) { ... }// Extra large devices (large desktops, 1200px and up)@media (min-width: 1200px) { ... }もともと Adventar の PC View は最大幅が 1000px で、992px, 1200px あたりは不要だったので、576px と 768px だけ採用し、以下の3パターンに絞りました。サイズ幅Smallwidth Medium576px Large768px SmallMediumLargeモバイルファーストで作るPC 用のスタイルを画面の小さいスマホ向けに変更していくのはけっこう難しいのと、基本的に PC で開発するのでモバイルの確認が漏れがち、などの理由があり、モバイル向けの画面をプライマリで作り、そこから幅を広げた場合の画面を作っていくことにしました。実装としては、メディアクエリに max-width でなく min-width を使うのがポイントです。例えば480pxをブレイクポイントにしてスタイルを変更するケースを考えてみます。max-width を使うとこうです。// PC 用.btn {  font-size: 20px;}// スマホ用@media (max-width: 480px) {  .btn {    font-size: 14px;  }}min-width の場合はこう。// スマホ用.btn {  font-size: 14px;}// PC 用@media (min-width: 481px) {  .btn {    font-size: 20px;  }}基本的には media query で元スタイルを上書きしていくほうがやりやすいので、min-width を使うと自然と画面が小さいサイズ向けのスタイルがプライマリになります。まとめUI をモバイル対応した話を書きました。明日は細かすぎて伝わらない UI の工夫について書こうと思います（ネタ切れです）。

View のモバイル対応

Adventarを支える技術 Advent Calendar 2019 の20日目です。今日はエラートラッキングについて書きます。Bugsnagエラートラッキングのサービスは色々あって、有名なのは Sentry や Airbrake あたりでしょうか。今回は Bugsnag というサービスを利用しました。これは Rails 時代から使っていて、無料で使える範囲が一番大きそう、という基準で選びました。Bugsnag だと 250 events/day は無料枠で使えるので、Adventar  ぐらいの規模であればスパイクしなければ余裕です。Sentry も今見たら無料で 5000 events/month なのでこっちでもいけそうな気がします（昔からこうだっけな）。今回は Go の gRPC サーバー、Nuxt.js で SSR しているところに Bugsnag を使っています。フロントエンドの JS でも動くのですが、経験上フロントエンドでのエラートラッキングはノイズが多く、無料枠を食いつぶしてしまう可能性がありそうだったので今回は入れていません。もしかしたらそんなことはなくて、意外とさくっといける可能性はあります。Rails では何もはまらずに使えていたのですが、Go と Node.js に有効にするのにけっこう苦労したので、それについて書いておきます。Go/gRPCでの利用Bugsnag の Go SDK はいくつかのフレームークに対応してますが、gRPC はありませんでした。https://docs.bugsnag.com/platforms/go/なのでOther Go appsを見て自力でどうにかする必要がありそうです。Go のサーバーでエラーをトラッキングしたいのは主に予期せぬエラーになった場合panic で死んだ場合の2つで、この場合にbugsnag.Notify(err, ctx)を呼べばよさそうです。最終的には以下のようなコードを Interceptor に刺しこみました。func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (_ interface{}, err error) {    defer func() {        if r := recover(); r != nil {            err = grpc.Errorf(codes.Internal, "Internal Server Error")            fmt.Printf("%s\n", r)            if bugsnagAPIKey != "" {                bugsnag.Notify(fmt.Errorf("%s", r), ctx)            }        }    }()    resp, err := handler(ctx, req)    s, _ := status.FromError(err)    if s.Code() == codes.Unknown {        stacktrace := fmt.Sprintf("%+v\n", err)        fmt.Print(stacktrace)        if bugsnagAPIKey != "" {            bugsnag.Notify(err, ctx, bugsnag.MetaData{"info": {"stacktrace": stacktrace}})        }        err = grpc.Errorf(codes.Internal, "Internal Server Error")    }    return resp, err},https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/api-server/grpc-server/service/service.go#L75-L96今回エラーハンドリングには xerrors を使っているのですが、xerrors で wrap したエラーを投げると、bugsnag 上でのエラーが全部 *xerrers.Wrap になるの困っています。どうにかしたいのですが、エラーの量もそこまで多くなくて困らないので放置しています。また、スタックトレースの情報がわかりづらく、例えば以下のエラーは以下の箇所で発生していますが、entry.go:118 がスタックトレースに表示されません。https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/api-server/grpc-server/service/entry.go#L118この問題はメタデータとして、fmt.Sprintf("%+v\n", err)を送信することで一時しのぎしています。これは以下の表示されます。わかりやすい...。もう少しちゃんとしたやり方があると思うので直したいところです。Node.js/AWS Lambdaでの利用SSR している Lambda では express を利用しているので、ドキュメントに沿って導入してみたが動きませんでした。どうやら bugsnag へのエラー送信が終わる前に Lambda が終了してしまうことが原因みたいだったようです。Issueもありました。https://github.com/bugsnag/bugsnag-js/issues/495エラーを送信する処理（bugsnagClient.notify）を自分で実行して、その終了を待てばよさそうなのですが、必要な情報を自分で詰めないといけないのでややめんどうでした。例えば express plugin を使えばこのあたりでやってくれます。https://github.com/bugsnag/bugsnag-js/blob/96238c360d1f021af9d006fead5d10f827cf0079/packages/plugin-express/src/express.js#L64-L76とりあえず最低限の情報だけ詰めて対応しました。app.use((err, req, _, next) => {  const opt = {    request: {      headers: req.headers,      httpMethod: req.method,      url: req.url    }  }; // このコールバックでエラー送信の終了を待つ  bugsnagClient.notify(err, opt, () => {    next(err);  });});https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/frontend/server.ts#L60-L69また、もう一つの問題は source maps です。https://docs.bugsnag.com/platforms/javascript/source-maps/ブラウザの JS であれば、sourceMappingURL に書いてある URL に取りに行ってくれるので便利ですが、Node.js の場合は source maps のファイルを別途 Bugsnag にアップロードする必要があります。がんばればできそうですが、今回はめんどうなので諦めました。いつかやるかもしれません。まとめ今回は Bugsnag を導入するのにはまったことなどを書きました。実際 Bugsnag はかなり役に立っていて、Bugsnag のおかげでいくつかのエラーを特定して潰すことができました。いくつか中途半端になっているところがあるので今後改善していきたいと思います。明日は UI のスマホ対応について書きます。

Bugsnagを利用したエラートラッキング

Adventarを支える技術 Advent Calendar 2019 の19日目です。今日は Server Side Redering (以下 SSR) した結果を CDN でキャッシュする戦略について書きます。SSR の概要については以下にも概要を書いたので一読しておくとよりわかりやすいと思います。上記に書いてありますが、今回は SSR を Lambda で行っていて、Lambda の実行はそんなに速くないし、実行回数での課金になるので、前段の CDN でキャッシュすることで、パフォーマンスとコストを最適化することができます。その設計について書こうと思いますが、、先に書いておくと今回は SSR の結果をキャッシュせずに毎回リクエストのたびに Lambda を実行しています。そのあたりの理由も含めて書いていきます。キャッシュのパージキャッシュはやれば速くなるのは確実ですが、コンテンツが更新されたタイミングで適切にパージしないと、新しいコンテンツがユーザーに届きません。パージの戦略は提供するコンテンツやキャッシュする範囲によっても様々です。例えばブログサービスのようなサイトでページキャッシュするケースを考えてみます。単純に考えると、ブログ記事が更新されたときに対象のブログページだけパージすればよさそうですが、キャッシュする範囲によってはその限りではありません。例えばブログにコメントや Like のような機能があって、それらも含めてキャッシュしているならコメントや Like が更新されたタイミングでも必要かもしれません。また、トップページや最新記事一覧ページのようなところに記事のコンテンツが表示されていて、それらのページもキャッシュしているなら、すべての記事作成、更新でそれらのページのパージが必要です。さらに、はてなブログのようなログイン機能があったらどうでしょう。ログインしている状態でキャッシュをつくると最初にキャッシュしたときにログインしているユーザー情報が全員に表示されてひどいことになります。そんなことないだろ、と思うかもしれませんが気をつけていてもミスによってそういった状態になってしまう例をいくつも見てきました。最近ではメルカリのニュースが記憶に新しいです。なのでキャッシュは狭い範囲で必要最小限に留めるべきです。例えば上記のようなブログサービスの例であれば、コメントや Like、ユーザー情報の表示はクライアント側（JS）でレンダリングする、キャッシュするのは記事ページのみに留める、などです。今回の Adventar でも、キャッシュはカレンダーページ（ https://adventar.org/calendars/3860 のようなページ）だけに留め、ログイン情報も SSR では扱わず、クライアント側で認証情報を付け足す、という設計にしました。認証については以下に書きました。これで、キャッシュする範囲は最低限ですが、それでもパージするタイミングは少なくありません。カレンダーのタイトル、概要の更新エントリの登録・編集・削除ユーザー情報（名前、アイコン）の変更デプロイなどです。このような操作が行われたときに、どうやってパージするかを見ていきましょう。Fastly によるパージまず最初にこの設計を考えたときに一番手にあがったのは Fastly です。Fastly には Instant Purge という機能があり、パージリクエストをして 150ms 以内にキャッシュをパージしてくれます。https://www.fastly.com/products/web-and-mobile-performance/caching-and-purgingパージの速さはユーザー体験につながるので、ぜひこれを使いたいところです。Fastly で具体的にどのようにパージするかを説明します。カレンダーのタイトル、概要の更新エントリの登録・編集・削除これらは単純で、該当カレンダーページのキャッシュだけをパージすればいいだけです。Fastly のパージは非常にシンプルで、該当の URL に PURGE メソッドでリクエストするだけです。https://docs.fastly.com/api/purge$ curl -X PURGE https://adventar.org/calendars/1だけで済みます。特別なクライアントもいらず、非常に簡単です。ユーザー情報（名前、アイコン）の変更はもう少し複雑で、そのユーザーが登録しているカレンダーページをすべてパージする必要があります。一つ一つ丁寧に上記のPURGEメソッドでパージすることもできますが、数が多くなると負荷も大きくなりますし、fastly の API Limit もあります。こういうときに使えるのが  Surrogate-Key という機能です。https://docs.fastly.com/en/guides/getting-started-with-surrogate-keysこの機能を使うと、キャッシュをタグのようなものでグルーピングして一括パージすることができます。リクエスト時にこのヘッダに複数の値を指定します。例えばSurrogate-Keyの値にu1 u2 u3のように、そのカレンダーに登録しているユーザー ID のをもたせておきます。そして user_id: 1 のユーザーがプロフィールを更新したら、u1 を指定してキャッシュをパージすることができます。デプロイデプロイ時にはすべてのキャッシュを消す必要がありますが、それは purge_all という API があるのでこれを使います。https://docs.fastly.com/api/purge#purge_bee5ed1a0cfd541e8b9f970a44718546このように、やりたいことは完璧に実現できそうだったので Fastly を使いところではあったのですが、Fastly の料金は最低料金が $50/month ということで、コスト面が折り合わず今回は断念しました。一方 CloudFront は、最低利用料金がなく、転送量だけであれば先日の記事にも書いたように、最もアクセスが多い12月でも$30〜$40ぐらいで落ち着きそうで、1月〜10月はほぼアクセスがないのでこれの 1/10 ぐらいに収まると思っています。個人サービスの上に1円も稼いでいないサービスなので $600/year はけっこうきついので、今回は CloudFront を採用しました。なお、Fastly にはオープンソース向けの無償アカウントがあるので、これを申請してみようかと思っています。https://docs.fastly.com/en/guides/accounts-and-pricing-plans#free-open-source-developer-accountsCloudFront によるパージまず、CloudFront のパージは Fastly ほど高機能ではありません。パージの速度も Fastly ほど速くありません（公式のドキュメントが見つけられませんでしたが、少なくとも ms のオーダーではない）し、Surrogate-Keyのような機能もありません。それだけであれば許容できると思ったのですが、調べてみると思ったよりパージに料金がかかることがわかりました。https://aws.amazon.com/cloudfront/pricing/月間で無効をリクエストしたパスの最初の 1,000 パスまでは追加料金なし。それ以降は、無効をリクエストしたパスごとに 0.005 USD かかります。どのぐらいパージ処理が走りそうかを概算してみます。カレンダーのタイトル、概要の更新ユーザー情報（名前、アイコン）の変更デプロイについては、回数も多くないし一旦無視します。問題はエントリの登録・編集・削除です。去年ベースで考えるとエントリの数は13767、そのうちコメントが更新されているもの12063、URL が更新されているものが11893でした。Adventar ではこれらの更新処理はタイミング的に別々に行わられるので、単純に足し算になります。さらに削除や、コメントやURLを複数回変更する場合もあります。ここではざっくり全体の10%ぐらいで計算してみます。13767 + (12063 * 1.1)  + (11893 * 1.1) = 40118.6これらはほぼすべて11月、12月で呼ばれるので、その2ヶ月でどのぐらいかかるかを出してみます。また、無料枠が 1000req/month あるので、それも加味します。(40118.6 - 2000) * 0.005 = $190.593だいたい $100/month くらいといったところです。ざっくり計算ですが、カレンダーや登録数は年々線形に伸びているし、もっと多くなる可能性もありそうです。11月と12月以外は無料枠に収まると思うので、トータルで見ると Fastly よりは安く済みそうですが、ピーク時のコストを10,000円前後ぐらいで考えていたので少し厳しい金額です。なので、今回は CDN によるキャッシュを諦め、毎回 Lambda を実行することにしました。ちなみにこれによって Lambda の実行回数は多くなりますが、昨日の記事にも書いたように Lambda のコストは $0.4 ぐらいになりそうです。爆安。まとめSSR の結果を CDN でキャッシュする戦略と、コスト面でその戦略を諦めた話を書きました。キャッシュによるパフォーマンスの最適化はユーザー体験にかなり寄与すると思っているので、Fastly のオープンソース向けの無償アカウントなどでコスト面の折り合いがつけばまたチャレンジしたいと思っています。明日は Bugsnag によるエラートラッキングについて書きます。

SSR の CDN によるキャッシュ戦略

Adventarを支える技術 Advent Calendar 2019 の18日目です。昨日の記事で実際にかかっているコストを紹介しましたが、今日はコストを最適化するためにやったことを書きます。Lambda を活用とスペックの調整昨日の記事を見ても分かる通り、ECS などと比べると Lambda のコストは爆安です。今回、Nuxt.js のサーバーサイドレンダリングを Lambda でやっていて、キャッシュはしていないので、カレンダーページへのリクエストごとに Lambda が実行されます。実行回数はこの function が支配的ですが、その他にも画像サーバーやバッチジョブなどにも Lambda を利用しています。現時点で実行回数は15万回ぐらいで、おそらく30万回ぐらいで着地すると思います。無料利用枠が10万回分、その後は10万回ごとに $0.2 なので、$0.4 ぐらいで収まる計算です爆安ですね。実行回数だけでなく、実行時間でも課金されますが、こちらは現在無料枠の半分以下なので無料枠で収まりそうです。なお、実行時間の課金は利用しているメモリの容量が関係します。https://aws.amazon.com/lambda/pricing/Serverless Framework ではデフォルトのメモリが 1024 MB になるので、大量に呼ばれる関数には適切に設定してあげないと、思いがけずコストがかかってしまうことがありそうです。今回は大量に Nuxt.js の SSR は 512 MB に設定しました。https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/frontend/serverless.yml#L16これがデフォルトの 1024 MB だと実行時間の計算は倍になり、無料枠の倍ぐらいの実行時間になりそうなので、400,000 * 0.0000166667 で $6.6 ぐらいになりそうです。大した額ではないですが。メモリの使用量は、Lambda のログに出力されます。REPORT RequestId: ee702bc9-c647-4d45-95c9-db8a2e6ba8bc Duration: 55.51 ms Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 224 MB現状 200 MB 〜250MB くらいなのでもう少し下げてもメモリは足りそうですが、メモリ使用量に比例して CPU の性能も決まるので、あまり下げすぎると性能が劣化します。実際、以下のように影響が出ています。カレンダーページのパフォーマンスに直結するので $6 ぐらいであれば 1024 MB に上げてもよさそうだなとこれを書きながら思いました。下げたときはどのぐらい呼び出しがあるか読めなかったのでビビってたのです。Fargate か EC2 かこれはコストを削減したというよりは、コスト削減と天秤にかけてメンテナンスコストが安いほうを選んだという話です。ECS はタスクを実行するのに EC2 インスタンスか Fargate を選べます。Fargate だと EC2 のインスタンスを管理しなくてよくなるし、スケールなども楽にできますが、EC2 より少し高くなります。また、EC2 の場合はデプロイ時に複数タスクを配置する必要があるので、余分にリソースを空けておきたいところです。Fargate の一番小さいサイズでもさばけそうだったので、Fargate は 0.25 CPU, 0.5 GB Memory、EC2 の場合は t3.micro（2vCPU, 1GB Memory）で比較しました。Fargate 約 $11/monthEC2(t3.micro) 約 $10/monthこれだとほぼ変わらないので、管理の手間などを考えて Fargate を選ぶことにしました。EC2 はもう一つ下の t3.nano でも足りるかも知れませんが、リソースが足りなくなってスケールアップ/アウトが必要になったときの手間を考えると選びづらい選択でした。また、スポットインスタンスなどを使えばもっと安く済みますが、さらに管理コストが増えるので採用は見送りました。ちなみにこのときはまだ Fargate Spot が発表されてなかったので試していませんが、時間があったら試してみたいと思っています。ちなみに以下は一番小さいサイズで余裕で捌けている図です。RDS のストレージサイズを小さくするこれはコスト最適化というよりは単純にミスったのですが、ストレージサイズを無駄に100GB確保しているのにリリースしたあとに気づいてしまって、途中で最小の20GBに落としました。https://github.com/adventar/adventar/commit/47d336c02a1619591ac33062e34022ab1a6ec356ストレージサイズを小さくするのは動かしながらはできないので、2台立ててアクセスが少ない時間帯に手動でデータをマイグレーションして切り替えました 😅 以下が切り替えたときのコストの変動です。これで $11/month ぐらい節約？できました。private subnet をおかない普通、VPC を設計する際、public subnet と private subnet を作り、インターネットから見える必要があるのもは public へ、そうでないものは private に置くことでセキュリティを強固にします。しかし、private subnet に置かれたサーバーからインターネットにアクセスしようとすると、Nat Gateway が必要になります。https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.htmlこの Nat Gateway が地味に高くて、起動しっぱなしだと、$40/month ぐらいかかります。必要なときだけ起動するみたいな方法もあるかもしれませんが、手間を考えて public subnet だけの運用にして Security Group でがんばる方針にしました。基本的な方針として、インターネットからのアクセスは ALB だけに許可して、その他のリソースはすべて VPC 内部からしかアクセスできないようにます。しかし、DB はデータや設定を見たりする用途で、手元からつなぎたいケースがけっこうあります。ただ、DB はインターネットからのアクセスを許可したくないリソース一番手でもあります。つなげるときだけ必要なものを詰め込んだ Fargate のタスクを起動して、一時的な踏み台として使う、という手も考えましたが、そこまでしなくてもいいかと思い止まり、手元の IP を許可した Security Group を作って、必要なときだけ RDS に刺すようにしました。https://github.com/adventar/adventar/blob/275aca335a2b195ca92d8ece131678dd8860f0a5/terraform/rds.tf#L23この Security Group は terraform で管理せずに手積みで管理しています。まとめ今日はインフラのコストを最適化する話を書きました。明日は SSR を CDN でキャッシュする戦略について書きます。

インフラコストの最適化

Adventarを支える技術 Advent Calendar 2019 の17日目です。Adventar の運用コストが、何にどのぐらいかかっているかを書きます。AWS 以外は無料のサービスしか利用していないので、かかっているのは 100% AWS のコストです。AWS の構成については先日書いたので、こちらも参照してください。今年の11月に新システムに移行したので、11月からのコストを見てみます。12月16日の時点でコストはこのような感じです。ピーク時（12月）で月10,000円以内ぐらいを目安に設計していて、この中に Adventar 以外のサービスのコストが $10 ぐらい含まれているので、概ね予定通りといったところです。内訳はこのような感じです。（月半ばの金額なので月額ではこれの倍かかる予想）今回 EC2 のインスタンスは使っていないので、EC2 となっているのは ALB です。その他については以下のようになっています。Lightsail は Adventar と関係ない個人で使っているやつなので、その他ではFargate: $5Route53: $3データ転送量: $3CloudWatch: $1といったところです。RDS や ALB、Fargate については、このぐらいかかると見込んでいたので予想通りでした。思ったよりもかかっていたのが CloudFront と API Gateway です。これらはリクエスト数がもろに料金に反映されます。アクセス数と料金の変異を見るとばっちり一致します。アクセス料金なので、ピーク時期がすぎればもう少し落ち着いて、コスト的には半分ぐらいで落ち着くのではと思っています。逆に、そうなってくると Fargate や RDS などの、常時起動しておく必要があるリソースのほうが支配的になってくるはずです。また、S3 や Lambda はヘビーに使っているにも関わらず、ほぼ無料で使えているのもわかります。まとめAWS のコストについて書きました。明日は AWS のコストを削減するためにやった細かい話を書きます。

Adventar のインフラコスト

Adventarを支える技術 Advent Calendar 2019 の16日目です。今年の Adventar のインフラはほとんど AWS を使って構築しています。AWS 以外だと、 Firebase Authentication や Bugsnag などのサービスも使っていますが、今回は AWS の構成について説明します。インフラの構成は基本的に terraform で管理していて、コードは以下にあります。API Gateway や Lambda の管理には Serverless Framework、ECS の管理には ecs-cli を使っていたりするので、それらは terraform 外での管理になっています。https://github.com/adventar/adventar/tree/619f222b9348e1cbfcfe50cc731fb8184e84ab2d/terraform構成図は以下のような感じです。それぞれ説明していきます。www.adventar.orgこれは最も簡単なシステムで、www.adventar.org というドメインの旧 URL を www なしの adventar.org にリダイレクトするためだけの存在です。S3 には、空の bucket を使ってホスト名のリダイレクトができるという機能があるのでこれを使っています。https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.htmlS3 の設定は簡単で、これだけです。https://github.com/adventar/adventar/blob/619f222b9348e1cbfcfe50cc731fb8184e84ab2d/terraform/s3.tf#L42-L54http だけであればこの bucket にエイリアスレコードを設定すれば終わりですが、httpsも対応したいので、CloudFront に ACM の証明書を刺して https も受けられるようにしています。img.adventar.org画像のリサイズサーバーです。詳細は以下に書きました。上記の記事でも書いたとおり、DB や API サーバーに依存しないので、構成をシンプルに保つことができます。adventar.orgユーザーフェイシングな HTML や静的ファイルのリクエストを受けます。詳細は以下に書きました。図にもあるように、SSR をしている Lambda が API サーバーへリクエストしています。このリクエストは本来は VPC 内部で Lambda を起動して内部通信するのがいいのですが、めんどくさいのでインターネット経由になっています。api.adventar.orgAPI サーバーです。VPC の中に配置した ALB がリクエストを受けて、その後ろにいる ECS がいて、ECS では Fargate でタスクがいて、Envoy と Go による gRPC のサーバーが動いています。DB は同じ VPC に配置されている RDS です。gRPC や Envoy の話は以下に書きました。バッチジョブVPC の中にいる CloudWatch Events と Lambda は、定期実行されるバッチジョブです。詳細は以下に書きました。まとめAdventar の AWS の構成についての概要を書きました。明日はインフラのコストについて書こうと思います。

Adventar のインフラ概要

Adventarを支える技術 Advent Calendar 2019 の15日目です。今日は DB のスキーマ管理について書きます。Rails の DB マイグレーションと RidgepoleAdventar は昨年まで Rails で作っていて、DB の マイグレーションも Rails デフォルトの機能を使っていました。Rails の DB マイグレーションは、それなりによくできてはいますが、差分を積み上げていくので大量のマイグレーションファイルができて煩雑になる、多人数での開発の場合にコンフリクトしやすいなど、いくつか問題があります。個人的にはこういった問題もあるので、Ridgepole のように DB のスキーマ定義だけを管理し、現在のスキーマとの差分を計算して ALTER 文を発行してくれるような仕組みのほうが好きです。最初は Ridgepole を使おうと思ったのですが、API サーバーは Go で書こうと思っていたので、スキーマ管理のためだけに Ruby 依存を入れるのは微妙かな、と思い他のツールを検討しました。schemalex と sqldefGo 製の Ridgepole 的なツールはhttps://github.com/schemalex/schemalexhttps://github.com/k0kubun/sqldefの2つがあるのを知っていたので、どちらかを使うことにしました。これらのツールは、Ridgepole と違って、Ruby の DSL でなく、SQL でスキーマを管理できる点、Ruby のランタイムなどが不要でバイナリ単体で実行できて便利です。ほとんど機能の違いはなのですが、大きい違いは schemalex が MySQL だけをサポートしているのにたいして、sqldef は PostgreSQL もサポートしています。今回は MySQL なのでどちらでもよかったのですが、schemalex のほうが歴史が深く、どちらかといえば安定していそうだったので schemalex を選びました。ちなみに、偶然にも Ridgepole, schemalex, sqldef は全部同僚 or 元同僚が作っています。schemalex による DB のマイグレーションスキーマの管理には、以下のような普通の SQL の DDL を使います。CREATE TABLE `users` (  `id` int unsigned NOT NULL AUTO_INCREMENT,  `name` varchar(255) NOT NULL,  `auth_uid` varchar(255) NOT NULL,  `auth_provider` varchar(20) NOT NULL,  `icon_url` text NOT NULL,  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,  PRIMARY KEY (`id`),  UNIQUE KEY `index_users_on_uid_and_provider` (`auth_uid`,`auth_provider`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;実際の Adventar のスキーマは以下のような感じです。https://github.com/adventar/adventar/blob/619f222b9348e1cbfcfe50cc731fb8184e84ab2d/db/schema.sqlこれはただの SQL なので、schemalex を使わずとも、初回のテーブル作成はできます。$ mysql -u root adventar_dev < schema.sqlここで新しくカラムを追加したい場合、例えば以下のような変更を加えます。--- a/db/schema.sql+++ b/db/schema.sql@@ -1,6 +1,7 @@ CREATE TABLE `users` (   `id` int unsigned NOT NULL AUTO_INCREMENT,   `name` varchar(255) NOT NULL,+  `description` text NOT NULL,   `auth_uid` varchar(255) NOT NULL,   `auth_provider` varchar(20) NOT NULL,   `icon_url` text NOT NULL,schemalex を使うと、既存の DB のスキーマと上記 SQL の diff を計算して ALTER 文を作ってくれます。$ schemalex 'mysql://root@tcp(127.0.0.1:13306)/adventar_dev' schema.sqlBEGIN;SET FOREIGN_KEY_CHECKS = 0;ALTER TABLE `users` ADD COLUMN `description` TEXT NOT NULL AFTER `name`;SET FOREIGN_KEY_CHECKS = 1;COMMIT;schemalex がやってくれるのは ALTER 文の生成だけなので、MySQL に食わせるのは自分でやります。$ schemalex 'mysql://root@tcp(127.0.0.1:13306)/adventar_dev' | mysql -u root adventar_dev実際の運用複数人で運用するときのフローや、デプロイ時に適用場合のフローなども紹介できればよかったのですが、Adventar はほぼ一人で開発しているし、プロとして恥ずべき行為ではありますが、デプロイも手元から手動でやっているので、特に運用について言及できることはありませんでした（つまり手動 ALTER でも十分そうということですね...！）まとめDB のスキーマ管理とマイグレーションについて書きました。明日は Adventar のインフラ構成について書きます。

schemalex による DB のスキーマ管理

Adventarを支える技術 Advent Calendar 2019 の14日目です。今日は Lambda , API Gateway, CloudFront などを使って、画像のリサイズサーバーを作る話を書きます。Adventar における画像のリサイズAdventar は記事を投稿した際に、記事の関連画像を取ってきて表示する機能があります。これは OGP などのメタタグから画像の URL を取得していますが、取得した URL をそのまま使用して画像を取得すると、いくつか問題があります。毎回リクエストが飛ぶので行儀が悪い画像の URL がhttp（非 SSL) の場合に mixed contents になる画像サイズが大きいとパフォーマンスに影響する（OGP の画像は 1000px 超えで設定してるケースも多い）Adventar でほしいのはせいぜい、100px〜200pxぐらいこれを解決するために、取得した画像をhttpsで配信し、適切なサイズにリサイズし、キャッシュするようなサーバーがあるとよさそうです。画像のリサイズは Fastly や ImageFlux などのサービス、ngx_small_light などの OSS を使うなど、様々な方法がありますが、今回は自前で画像を持っているわけではなく、外部サイトの画像を取得して利用したいという少し違うユースケースというのもあり、Lambda と CloudFront で自作することにしました。といっても全然難しい仕組みではなく、画像 URL を受け取ってリサイズして画像を返す Go のプログラムを Lambda で動かして、CloudFront でキャッシュしているだけです。Go のコードも100行ちょっとの簡単なものです。https://github.com/adventar/adventar/blob/10b9b2386f76d1fd66c10c31d4dd0550f6d0527d/image-server/main.goいくつか工夫していているとこがあるので説明します。DB に依存させないまず、一つ目が DB に依存せずに動作させるということです。画像の URL は、DB に保存されていますので、画像 URL を知るためには、カレンダーの投稿 ID を受け取って DB にアクセスし画像 URL を取ってくる、ということが必要になりますが、そのためだけに DB にアクセスするのはめんどくさいので、今回はリクエスト URL に直接画像の URL を埋め込んでいます。https://img.adventar.org/?url=<画像URL>のような感じです。Lambda でこの画像 URL を fetch して、適当なサイズにリサイズして返します。本当はサイズの指定もクエリでできるようにしたいのですが、とりあえず今は1サイズしかないので固定にしています。https://github.com/adventar/adventar/blob/10b9b2386f76d1fd66c10c31d4dd0550f6d0527d/image-server/main.go#L84ハードコードでだいぶひどい感じですが、かなりギリギリになって実装したので雑コードです（投稿が始まる12月までにあればいいので実装を一番最後に回した）。ダイジェスト値による検証ただ、これだと任意の URL のプロキシになってしまってよろしくないので、ダイジェスト値を設定して URL が改ざんされていないかを検証しています。OSS なのでコードを読めばわかりますが、単に画像 URL  に SALT を混ぜて sha1 を取っているだけの簡単なものです。なので最終的な URL はこのような感じになっています。https://img.adventar.org/img/<digest>?url=<画像URL>実際の URL はこんな感じです。https://img.adventar.org/img/c96546f133a9e2803dd7bb033681ffcf81146cb0?url=https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhokaccha%2F20191203%2F20191203213418.pngデプロイフロントエンドのデプロイ や バッチジョブのデプロイ にも利用した Serverless を利用しました。今回 Serverless 大活躍です。設定はこんな感じで何も難しくない。https://github.com/adventar/adventar/blob/10b9b2386f76d1fd66c10c31d4dd0550f6d0527d/image-server/serverless.ymlデプロイスクリプトも$ serverless deployで終了。https://github.com/adventar/adventar/blob/10b9b2386f76d1fd66c10c31d4dd0550f6d0527d/image-server/Makefile#L10まとめLambda を使った画像のリサイズサーバーについて書きました。明日は DB のスキーマ管理について書きます。

Lambda を使った画像のリサイズサーバー

Adventarを支える技術 Advent Calendar 2019 の13日目です。今日は定期ジョブの実行について書きます。定期ジョブというのは cron とかで定期的にプログラムを実行するやつのことです。実行するプログラムAdventar では、定期ジョブは一つだけしかなくて、定期的に投稿された URL のメタデータをフェッチしてくる、というものです。Adventar は自分の担当の日に URL を投稿すると、その URL のタイトルと画像を取ってきて表示する機能があります。普段は URL を投稿するリクエスト中でその処理をしていますが、これだと予約投稿のような機能を使いたいときに困ります。例えば 12/10 に自分の番がくるけど、記事はその前に書いて hatena blog の予約投稿で 12/10 の 0 時に公開されるように設定しておく、Adventar にも前日までにその URL をセットしておく、というのはユースケースとして考えられます。なお、このとき Adventar はその日にならないと投稿した URL は投稿者以外からは見えないようになっています（ネタバレになると面白くないので）。しかし、URL が Adventar に登録された時点では hatena blog のほうもまだ公開されていない状態なので、タイトルや画像が取れません。そこで、1時間に一回定期ジョブを実行して、その日に URL があるけどタイトルや画像が空のレコードに対して、その URL にアクセスしてメタデータを取ってくる、というジョブを動かしたいのです。ジョブのプログラムは簡単で、こんな感じです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/batch/update_entry_site_info/main.goCloudWatch Events と Lambda今回は常駐するサーバーがないので cron を実行する環境がありません。いくつか方法はありますが、CloudWatch Events を使うことにしました。CloudWatch Events は cron のような書式で定期的に何かの処理をトリガーすることができるので、今回はこれを利用します。CloudWatch Events のトリガーには様々なものが設定できますが、今回のケースは、Lambda か ECS tasks でプログラムを実行するのがよさそうです。どちらでもよかったのですが、Lambda であれば Serverless フレームワークを使って管理することができそうだったので、今回は Lambda で実行することにしました。追記: これを書いた後で諸事情により ECS に変更したので、現在は ECS で動いています。Serverless を使った設定特に難しいことはなくて、以下のような設定を書くだけです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/batch/serverless.ymlこれで Serverless が Go のビルドからデプロイ、CloudWatch Events の設定まで全部やってくれます。便利。注意しないといけないのは、時間が UTC でしか設定できないので、JST で 12/1 の 0 時から12/25 まで、という設定は書きのように少しトリッキーな記述が必要です。なお、これだと12/26にも少し実行されますが、実行されても害はないのでさぼってます。events:  - schedule: cron(0 15-23 30 11 ? *)  - schedule: cron(0 * 1-25 12 ? *)まとめ今日は Serverless で定期ジョブを管理する方法について書きました。明日は Lambda を利用した画像のリサイズサーバーについて書きます。

Lambda と CloudWatch Events を利用した定期ジョブを Serverless で管理する

Adventarを支える技術 Advent Calendar 2019 の12日目です。今日は API サーバーのデプロイについて書きます。API サーバーは、4日目の記事 でも書いたように、gRPC のサーバーをたてています。この API サーバーは、Amazon ECS, Fargate を利用してホストしています。ECS のデプロイツールは色々とあって、仕事で使っているのは hako というツールです。今回は他のツールも使ってみたいというのもあって、AWS 公式が提供している ecs-cli を使ってみました。https://github.com/aws/amazon-ecs-cliecs-cli の他の良い点としては、docker-compose.yml を設定ファイルとして使えるというところじゃないかなと思っています。docker-compose.yml  であれば、ツール独自のシンタックスを覚えなくても良いのがいいですね。ただ、当然のようにdocker-compose.yml だけでは足りなくて、ECS 独自の設定も別途必要になります。それはecs-params.ymlという設定ファルに書くのですが、設定ファイルが分散してしまうのが微妙という見方もありそうです。Adventar ではそれぞれ以下に設定があります。ecs-params.ymldocker-compose.ymlecs-cli のコマンドcompose create servicehttps://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose-service-create.htmlサービスを作ります。実行するのは初回だけです。ALB と target group は別途 terraform で作っています。$ ecs-cli compose --project-name adventar --cluster adventar --region ap-northeast-1 service create --create-log-groups --launch-type FARGATE --container-name envoy --container-port 80 --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:287379415997:targetgroup/adventar-api/xxxcompose service uphttps://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose-service-up.htmlこれが実質デプロイコマンドです。docker-compose.yml と ecs-params.yml の設定を見てタスク定義を作り、新しいタスクをデプロイしてくれます。$ ecs-cli compose --project-name adventar --cluster adventar service upなお、ドキュメントにはa combination of the create and start commandsとあるので、start でもいいのかと思いきや、start だと新しいタスクのデプロイは行わません。また、This command updates the desired count of the service to 1.とあるので、desired count が 2 以上だった場合は 1 になるのかと思いきや、既存の desired count をそのまま引き継いでくれます。ドキュメントを読んだだけだとこのあたりの挙動はよくわかりませんでした。compose service scalehttps://docs.aws.amazon.com/AmazonECS/latest/developerguide/cmd-ecs-cli-compose-service-scale.htmlタスク数（desired count）を変更します。$ ecs-cli compose --project-name adventar --cluster adventar service scale 2docker pushデプロイする際は、ECS のデプロイの前に docker push する必要があるので、git の HEAD の revision で tag を打って dockdr push してからデプロイしています。こんな感じです。TAG=$(git rev-parse HEAD)cd $ROOT_DIR/grpc-serverdocker build -t hokaccha/adventar-grpc-server:${TAG} .docker push hokaccha/adventar-grpc-server:${TAG}cd $ROOT_DIR/envoydocker build -t hokaccha/adventar-envoy:${TAG} .docker push hokaccha/adventar-envoy:${TAG}今回はコードもオープンですし、ECR は利用せずに Docker Hub の public なところに push しています。実際のデプロイスクリプトはこんな感じです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/api-server/bin/deployまとめAPI サーバーを ECS でデプロイする話しを書きました。明日は Lambda と CloudWatch Events を使った定期ジョブについて書きます。

ecs-cli を利用したAPI サーバーのデプロイ

Adventarを支える技術 Advent Calendar 2019 の11日目です。今日はフロントエンドのデプロイについて書きます。フロントエンドの構成は昨日の記事で書いたとおり、一部を Lambda で SSR していて、静的コンテンツは S3 で配信しています。なので、S3 と Lambda の両方にデプロイする必要があってやや面倒です。S3 へのデプロイまず、静的コンテンツの S3 へのデプロイ自体は簡単で、nuxt build で生成された成果物（デフォルトではdistディレクトリ）を S3 にアップロードするだけです。$ nuxt build$ aws s3 sync ./dist/ s3://your-bucket/prefixSSR しなければ、これだけで Nuxt.js のアプリケーションは配信できます。注意する点としては、SPA の場合クライアント側でルーティングするので、すべてのパスに対して index.html を返す必要があるという点です。CloudFront と S3 でやる場合は、ファイルが存在しない場合 CloudFront には S3 から 403 が返るので、これをハンドリングして index.html を返します。terraform で書くとこんな感じです。custom_error_response {  error_code         = "403"  response_code      = "200"  response_page_path = "/index.html"}https://github.com/adventar/adventar/blob/b491c3be64b8d35b3484b69e4f9ce8f6ecfb93eb/terraform/cloudfront.tf#L38-L42SSR のためのビルド今回、一部だけ SSR するという構成にしたのでめんどくさかった点がこれで、Nuxt.js は SPA の場合は spa mode でビルド、SSR の場合は universal mode でビルドする必要があります。https://nuxtjs.org/api/configuration-mode/なので、ビルドプロセスも両方でやる必要があるのですが、spa mode と universal mode でビルドした JS ファイルのダイジェスト値が微妙に食い違ったりしたということがありました。そうするとどうなるかという、spa mode でビルドして S3 にアップロードした中に、universal mode からで生成した HTML に含まれる JS のファイル名がなくて JS が 404 になって動かない、ということが発生しました。たぶんこんな使い方想定してないのでエッジケースだと思います。Nuxt.js を直すほどの元気はなかったので、universal mode でビルドした結果も S3 にアップすることでしのぎました。なんとかこれで動いてます。以下が苦肉の策のコードです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/frontend/bin/deploy#L11Serverless フレームワークを使った API Gateway と Lambda のデプロイ次に、SSR するための Lambda のデプロイですが、これには今回 Serverless Framework を使いました。API Gateway や Lambda のデプロイは、Serverless や AWS SAM などを使うと便利です。SAM でもよかったのですが、今回は知見のあった Serverless を採用しました。Serverless でのデプロイはそんなに難しいことはしていなくて、以下のような設定ファイルを書くだけです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/frontend/serverless.ymlこれで Nuxt.js のビルドを実行後に$ serverless deployで API Gateway と Lambda にデプロイできます。また、サーバーのコードも量が少ないとはいえ TypeScript で管理したいのと、一部クライアントの TypeScript のコードに依存があるので webpack で変換して bundle することにしました。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/frontend/webpack.config.server.js本当は Lambda にアップロードする容量を削減のため、必要なコードだけ bundle して一枚の JS にてアップロードしたかったのですが、色々とうまくいかずに bundle するのは諦め、webpakc で node_modules の解決は無視して、node_moduels をアップロードすることにして対応しました。Lambda の容量の上限に引っかかるほど大きくはないので一旦これで妥協しています。キャッシュのパージ今回 S3 にアップするアセットは CloudFront でキャッシュしています。JS や CSS はダイジェスト値がついていてファイル名がユニークになるのでキャッシュのパージは必要ありませんが、index.html や sw.js などはキャッシュのパージが必要です。また、本来は SSR した結果もキャッシュしたいと思っていたので、上記に書いたデプロイの処理をおこなったあとにキャッシュをパージする必要があります。CloudFront のキャッシュのパージは以下のようにします。aws cloudfront create-invalidation --distribution-id xxx --paths '/*'最終的な、デプロイスクリプトは以下ような感じです。https://github.com/adventar/adventar/blob/fa0714e49ea3aa60888532b60b924af0c12bbc80/frontend/bin/deployまとめフロントエンドのデプロイについて書きました。Nuxt.js と Serverless のおかげで、そんなに複雑には見えませんが、ここまでたどり着くにはけっこうな時間を消費しました...。明日はこの流れで API サーバーのデプロイについて書きます。

フロントエンドのデプロイ

Adventarを支える技術 Advent Calendar 2019 の10日目です。今日は Adventar の Server Side Rendering（以下 SSR）している技術構成について書きます。インフラ構成まず、先日の記事に書いたように、Adventar ではすべてのページを SSR しているのではなく、カレンダーの詳細ページだけを SSR しています。SSR するカレンダー詳細は API Gateway で受けて Lambda でレンダリングしており、そうでない静的なアセットは S3 で配信しています。その前段のルーティングは CloufFront でおこなっています。S3 で捌いているのは、JS や CSS などの静的ファイルは当然ですが、例えばトップページなどの HTML も S3 が返します。ただしこの HTML は SSR されていない、JS と CSS のリンクだけしかない HTML で、クライアントサイドで API を呼び出してコンテンツをレンダリングします。なぜ Lambda かLambda でも Cloud Functions でもよかったのですが、単に他のインフラ構成要素が AWS になったからで、Cloud Functions との技術的な比較はしていません。常駐型のサーバーと比べて Lambda などのサーバーレス環境を利用するのは、管理コスト（費用、手間）が安く済むというのが大きいでしょう。うまく使えば安く済むし、サーバーを管理しなくていいというのは非常に大きいメリットです。一方デメリットとしては、パフォーマンスなどが挙げられると思います。Lambda は遅くはないですが、コールドスタートなどのデメリットもあるし、常駐型のサーバーと比べるとパフォーマンスの最適化はしづらい側面があると思っています。これについては、先日発表された Provisioned Concurrency によって解決できるかもしれないですけどまだちゃんと試してません。https://aws.amazon.com/jp/blogs/aws/new-provisioned-concurrency-for-lambda-functions/今回は SSR した結果を CDN でキャッシュするという予定だったので、パフォーマンス、費用面ともに常駐サーバーよりは有利になる予定でした。前日にも書いたとおり、現状は一旦キャッシュの実装は見送って毎回 Lambda が呼ばれていますが、費用的にはサーバーを用意するよりは安く済みそうです。パフォーマンスは HTML のレスポンスタイムが200ms〜300ms ぐらいかかっているので、速くはないが、激遅でもないという感じです。Lambda で Nuxt.js の SSRNuxt.js は$ nuxt startで SSR なサーバーを起動することができ、レールを外れずに使う場合はこれでいいのですが、今回は Lambda を使って SSR したいのでこれは使えません。Nuxt.js はカスタムサーバーを利用する場合、nuxt.renderという express の middleware などと互換性のある API を提供しているのでこれを使います。https://nuxtjs.org/api/nuxt-render/また、Lambda で express などのサーバーを利用するための serverless-http というモジュールがあるので、これも利用します。https://www.npmjs.com/package/serverless-httpこれらを利用すると、以下のような感じで Nuxt.js を Lambda で利用できます。import { Nuxt } from "nuxt";import serverless from "serverless-http";import express from "express";import config from "~/nuxt.config";const app = express();const nuxt = new Nuxt(config);app.use(nuxt.render);module.exports.handler = serverless(app);他にも RSS などの動的コンテンツを同時に配信しているので、少し複雑になっていますが、コードは以下のような感じです。https://github.com/adventar/adventar/blob/b491c3be64b8d35b3484b69e4f9ce8f6ecfb93eb/frontend/server.tsこれを Lambda で実行すれば、クライアント側で同じコードで HTML が生成されて返ってきます。前述したように、API Gateway を通してカレンダーページだけでこれを実行しているわけです。まとめAdventar における SSR の技術構成について書きました。明日は SSR を含めた、フロントエンドのデプロイについて書こうと思います。

Server Side Rendering の技術概要

Adventarを支える技術 Advent Calendar 2019 の9日目です。Adventar のフロントエンドは Nuxt.js で SPA な構成ですが、一部で Server Side Rendering（以下 SSR）をおこなっています。今日は SSR をする理由や Adventar での導入方法について書きます。なぜ SSR するのかSPA で SSR が必要な理由は主にマシンリーダビリティ（SEO とか OGP とか）パフォーマンスの2つだと思っています。SPA は基本的に JavaScript で API を呼び出してコンテンツをレンダリングするので、JavaScript を理解できないクライアントには正しいコンテンツを提供できません。典型的な例は検索エンジンのクローラーや、OGP などでサイトのコンテンツを取得するケースです。SEO については最近のクローラーが JavaScript を理解してくれるので SSR 必須ではないと思います。OGP は、Adventar においてはカレンダーページのタイトルと概要テキストだけどうにかできればいいので、Edge Side（Lambda@Edge など）でどうにかして差し込むなどの方法があるかもしれません。一方パフォーマンスについてはちゃんとやればかなり効果があると思っています。一般的な SPA をレンダリングする場合ユーザーがアクセスしてコンテンツをレンダリングするまでにはHTML を取得するJavaScript を取得するJavaScript を実行して API コールするAPI の結果を元に DOM を構築するというフローがあります。SSR だと最初の HTML を受け取った時点でコンテンツ情報もできているので、ユーザーは即座にコンテンツを閲覧することができ、パフォーマンス的には優位です。もちろん SPA が返す、JS と CSS 以外何もコンテンツがない HTML と比べると、SSR の HTML をつくる過程にはサーバー側で API コールなり、SQL の呼び出しがあり、それを元に HTML を構築する処理が走るので、SPA のような を作るよりも時間がかかります。とはいえ、ネットワーク的なレイテンシの少ない SSR のほうが基本的に速くなるほうが多いでしょう。しかし、サイトの特性によっては初回ロードの遅延がそこまで気にならない場合もあるでしょう。一方で、SSR によるパフォーマンス的な最大のメリットは、キャッシュによるパフォーマンス最適化がやりやすいところにあると思っています。SSR した結果を CDN などでキャッシュして適切にパージができれば、パフォーマンスは超速になります。ただし、このパージがけっこう大変で、当初は CDN でキャッシュするアーキテクチャを前提で設計していましたが、色々と考えた結果パージに思ったよりコスト（実装コスト、お金的なコスト両方で）がかかるので結局 CDN のキャッシュは今年はいったん諦めて、リクエスト毎に SSR しています。諦めた理由などについては後日詳しく書こうと思います。来年やれたらやりたいです。このように、ちゃんとやればいくつかのメリットがある SSR ですが、正直実装コスト、運用コストが高すぎてメリットに見合うかは微妙なところだと思っています。実際、今回実装してみてそれを実感しました。やはりブラウザとNode.jsという実行環境が全然違う環境で同一のコードを実行するというのは、理論上は可能でも色々と困難です。5日目の記事にもその一部を書きましたし、この他にも実装コスト、運用コストがかなり高いです。今回 Adventar で SSR を導入するのに費用対効果はあまり考えてなくて、単なる技術的なチャレンジという意味合いが強いです。Lambda を使ったサーバーレスな環境での SSR というのを試したかったので導入しました。どこに SSR を導入するか今回、まず決めたのは SSR において認証情報を扱わない、ということです。今回は認証に Firebase Authentication を利用しているのもあり、認証をクライアントサイドで行っており、最初のリクエストにセッション情報をリクエストしていません。Cookie に認証情報を乗せて頑張ればできないことはないのですが、API サーバーと SSR のサーバーで認証の機構を共有するなど、かなりの実装コストがかかりまし、SSR した結果を CDN でキャッシュする場合、レスポンスの HTML に認証された状態のものを乗せるのは複雑度が爆増するのが目に見てみます。また、SSR した結果をキャッシュに乗せることを考えると、キャッシュのパージ戦略を考える必要があります。キャッシュのパージは対象のコンテンツとページが多くなるほど複雑になって制御が難しくなるので、できるだけ局所的にするのが良いと思っています。そのような理由から、今回 SSR するのはカレンダー詳細ページだけに限定することにしました。カレンダー詳細ページというは以下のような画面です。https://adventar.org/calendars/3860この画面は、ソーシャルメディアなどでもよく共有されるので、OGP を SSR で埋め込む必要もあるし、アクセスの8割はこの画面に最初に着弾するので、初期描画のパフォーマンスが最適化されることに大きい意味があるためです。SSR 画面を限定したことで、すべて SSR するよりはトータルの実装コストは低くなったとは思いますが、最初にロードする画面が SSR 対象（カレンダー詳細画面）か、そうでないかによって微妙に挙動が変わって、どちらかでしか起きないバグが発生したり、デプロイのフローが複雑になったりと、それはそれで大変でした。まとめ今回は SSR のメリットや、Adventar における導入事例を紹介しました。明日はもう少し具体的な、Nuxt.js を Lambda で SSR する場合の技術的なトピックについて紹介したいと思います。

Adventar における Server Side Rendering の導入

Adventarを支える技術 Advent Calendar 2019 の8日目です。今日は Firebase Authentication で苦労した点や工夫した点について書きます。ログインの判定が遅い問題Firebase Authentication を使って、現在のセッションがログインしているかどうかを検出するには、firebase.auth().onAuthStateChanged()を呼び出します。https://firebase.google.com/docs/auth/web/manage-usersfirebase.auth().onAuthStateChanged(function(user) {  if (user) {    // User is signed in.  } else {    // No user is signed in.  }});しかし、この処理は呼び出してから初回のイベントが発火するのに数秒ぐらいレイテンシがあります。なので、愚直にこの機能を使うと、ページがロードされて、ログインしていれば数秒後にログインしている状態（自分のアイコンがヘッダに表示されたり、自分の投稿に編集ボタンが出たり）に切り替わる、ということになり、いい体験ではありません。そこでログイン状態は localStorage にキャッシュすることにしました。キャッシュしているコードはこのへんです。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/frontend/lib/Auth.ts#L118https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/frontend/store/index.tsキャッシュした情報は plugin でリストアしています。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/frontend/plugins/auth.tsこの処理は初期描画の直前に一回だけ実行されるので、描画と同時にログイン状態がわかります。機密情報をlocalStorageに保存するのはセキュリティ的なアレがありますが、今回保存するのは token そのものでなく、表示に必要なデータだけにしているのでそのあたりは安心です。これでほぼよさそうに見えますが、キャッシュの状態が不整合になる可能性を考えてみましょう。別タブでログアウトした/別のアカウントでログインしたログイン処理を終えてリダイレクトされて戻ってきた1 のケースは問題にならなくて、firebase.auth().onAuthStateChanged()のイベントはユーザーのログイン状態が変わったら発火するイベントリスナーなのですが、別タブでログイン/ログアウトしたような場合でもイベントが発火します。なので、別タブでログイン/ログアウトしてもユーザーの状態は同期されます。2のケースは、ログインプロバイダのログイン画面から戻ってきたときの話しです。ログイン画面から戻ってきた瞬間なので、キャッシュの状態は未ログイン状態のはずですが、実際にはプロバイダでのログインが成功していればログイン状態となるはずです。なので、キャッシュと実際の状態が不整合になるのは実はこの場合だけです。このケースは、ログイン処理中であるというローディングを出すことで対応しました。最初は画面全体をローディングにしていましたが、状態が変わってから再描画するところはそんなに多くなく、ログイン処理中というのがわかればいいので、ヘッダのアイコンのところだけ局所的にローディングすることにしました。ただ、プロバイダのログイン画面から戻ってきた、という状態を取る方法がなさそうだったので、リダイレクト前に sessionStorage に適当な値をセットして、次に初期化処理が走った場合はリダイレクトから帰ってきたとみなして、firebase.auth().onAuthStateChanged()が発火するまでローディングを出します。唯一不自然になるパスは、ログインを押してログイン画面に遷移後、ログインを完了せずに戻ってくるパターンですが、まあそんなに致命的な問題でもないので許容しています。アイコン URL が更新されない問題Adventar ではユーザーアイコンに OAuth でとってきた画像を使っています。例えば Twitter でユーザーがアイコンを変えた場合には Adventar でも新しいアイコンになってほしいので、ログインの処理のときにアイコンをアップデートする処理をいれています。コードはこのあたりです。https://github.com/adventar/adventar/blob/b73af145638e9f4d4da6655015786bdac54510eb/api-server/grpc-server/service/user.go#L47-L57しかしこれではダメで、Firebase Authentication は最初にログインしたときの情報を Firebase Authentication 側にストアしてもっているらしく、ユーザーが Twitter 側でアイコンを更新しても、Firebase Authentication 側のデータは更新されないようです。いくつか方法はありそうですが、一旦今はログアウト時に Firebase Authentication 側のユーザーを消すという方法を取っています。https://github.com/adventar/adventar/blob/b73af145638e9f4d4da6655015786bdac54510eb/frontend/lib/Auth.ts#L56export async function logoutWithFirebase() {  const user = firebase.auth().currentUser;  if (!user) return;  try {    await user.delete();  } catch (err) {    console.error(err);  }  await firebase.auth().signOut();}Adventar 側では特に Firebase Authentication の User ID などは使ってないので、ログアウト時に消しても問題ないためです。ただ、ユーザーとしてはアイコンを更新するためにログアウトが必要、というのは非常にわかりにくいので、もう少しいい方法を考えたいところです。Firebase Authentication でログイン時にプロバイダの API のアクセストークンが取れるので、それで API をこちらで叩いて最新のアイコンを取得して更新、という感じになるかなと思っています（が、けっこうめんどくさいので後回しになっている）。third-patry cookie が無効な場合にログインできない問題これはそのままなのですが、Firebase Authentication は third-patry cookie が無効な場合はログインが失敗するという問題があります。https://github.com/firebase/firebase-js-sdk/issues/934これはもう仕方ないので、ログイン時のエラーをハンドリングして、Cookie によるエラーの場合は third-party cookie が無効な可能性がある、というメッセージを表示することにしました。https://github.com/adventar/adventar/blob/b73af145638e9f4d4da6655015786bdac54510eb/frontend/lib/Auth.ts#L88-L92const COOKIE_ERROR_MSG =  "third-party cookie の設定が無効になってる可能性があります。ブラウザの設定をご確認ください。";const msg = err.code === "auth/web-storage-unsupported" ? COOKIE_ERROR_MSG : err.message;alert(`ログインに失敗しました。\n${msg}`);console.error(err);GitHub 認証の場合にユーザー名が空のケースがある問題Firebase Authentication から取得できる JWT の中には名前やプロフィールアイコンのURLなどが以下のような形で格納されています。{  "name": "Kazuhito Hokamura",  "picture": "https://lh3.googleusercontent.com/a-/AAuE7mDtNB98Nu2WHMoeBUs1x3XrNqCrav4GnZRTbwMB8g",  "user_id": "xxx",  "sub": "xxx",  "iat": 1234567890,  "exp": 1234567890,  "firebase": {    "identities": {      "google.com": [        "xxx"      ]    },    "sign_in_provider": "google.com"  }}この name や picture がそうです。Google や Twitter などのプロバイダに設定してある名前やアイコン画像が取れるのですが、GitHub の場合、name が含まれない場合がありました。GitHub は名前の入力が必須ではないので、入力してないユーザーの場合はこのフィールドがない状態の token になります。名前は必ず存在する、という前提でコードを書いていたので、そのような状態のユーザーがログインしようとするとエラーになってログインできない状態になっていました。空の場合は user_id （github.com/xxx の xxx）の部分が取れればいいのですが、Firebase Authentication 経由だとその情報は取れなさそうだった（もちろん自前でアクセストークン使って GitHub の API を自前で呼び出せばとれますが）ので諦めて"No Name"のような名前でユーザーを作ることで対応しました。https://github.com/adventar/adventar/blob/b73af145638e9f4d4da6655015786bdac54510eb/api-server/grpc-server/util/auth.go#L47-L51まとめFirebase Authentication でハマった点などをいくつか紹介しました。慣れてないので色々とハマりましたが、やはり自前で認証の仕組みを用意するのに比べると格段に楽でよかったです。明日は Server Side Rendering のについて書きます。

Firebase Authentication の苦労話

Adventarを支える技術 Advent Calendar 2019 の7日目です。今日は Firebase Authentication 認証について書きます。選定理由まず、なぜ今回 Firebase Authentication を利用することに決めたかを説明します。検討した選択肢としてはFirebase AuthenticationAmazon CognitoAuth0自前でがんばるあたりです。このうち自前でがんばるのは大変なので最後の手段とし、可能な限りマネージドなサービスを検討しました。Rails 時代はセッションを Cookie ストアにしていたので、サーバー側でデータストアが不要だったりしてそんなに面倒ではなかったのですが、安全面を考えると Cookie ストアはやめたいと思っていたし、JWT にするにしても、結局安全面を考えると expire を短くしてリフレッシュトークンを使うことになりますが、リフレッシュトークンの管理をするのが面倒だったりします。なのでそのあたりをマネージドでできるのであればマネージドがいい。マネージドサービスを検討するにあたり、考えないといけなかったのは過去のデータとの互換性です。ログインシステムを変更することで過去に作ったカレンダーや投稿を管理できなくなるのは避けたいところです。Adventar ではこれまで、認証には omniauth という Gem を利用していました。omuniauth は色々な OAuth プロバイダを利用して認証システムを作ることができるライブラリです。Adventar では Google, Twitter, Facebook, GitHub をプロバイダとして利用していました。なので、前提条件として、Google, Twitter, Facebook, GitHub の OAuth には絶対に対応している必要がありました。それを考えると Amazon Cognito は Twitter, GitHub のログインに対応していないので採用を見送りました。Auth0 と Firebase Authentication はどちらも要件を満たしていましたが、Firebase Authentication はなんと無料で使えるということだったので、Firebase Authentication が今回のユースケースで使えるかを検証し、問題なさそうだったので今回利用を決めました。Auth0 も Adventar ぐらいの規模だと無料か一番安いプラン（$23）ぐらいで利用できそうではありましたが、個人開発にとって $23 はかなりでかいのです。アーキテクチャFirebase Authentication は Firebase のその他の機能と連携すると、おそらくそんなに面倒なことはないのですが、今回は Firebase Authentication 以外に Firebase の機能は使わないので、Firebase Authentication を使った認証の仕組みを自前のサーバーに組み込む必要があります。サーバー側が必要な情報は、ログインプロバイダと OAuth の uid 、名前とプロフィールアイコンの4つです。旧システムではログインプロバイダと OAuth の uid ユーザーの組み合わせを一意なユーザーの識別子として利用していたので、これがないとユーザーの識別ができません。名前とプロフィールアイコンは表示に使うだけなので、あれば嬉しいという感じです。これらを Firebase Authentication の API から取得してサーバーに送ることができればいいわけです。Firebase Authentication ではまず最初に、クライアント側で認証の処理を行います。要点だけ説明していきますので、詳細はドキュメントを見てください。https://firebase.google.com/docs/auth/web/firebaseuiまず、ユーザーが Adventar から、「Google でログイン」を押すと以下の処理が実行されます（API Key などは別途設定しています）。firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());これでユーザーは Firebase Authentication のサイトを経由して Google 認証の画面に飛びます。ユーザーが Google の認証情報を入力して成功すると Adventar に戻ってくるわけですが、このとき以下のようなコードで JWT のトークンを取得することができます。firebase.auth().onAuthStateChanged(async user => {  const token = await user.getIdToken();});実際のコードはこのあたりです。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/frontend/lib/Auth.ts#L105-L127この token の実態は JWT で、前述したログインプロバイダ、uid、名前、プロフィールアイコンなどのほしかった情報が入っています。なので、これをサーバー側に投げれば Adventar が持っているデータと突き合わせてユーザーを識別できるのですが、この token が改ざんされていないかを確認するため、JWT の検証が必要です。https://firebase.google.com/docs/auth/admin/verify-id-tokens今回はアプリケーションサーバーに Go を使っていますが、Firebase Authentication の Go SDK に JWT の検証機能があるのでこれを使います。json := os.Getenv("FIREBASE_CREDENTIAL_JSON")if json == "" {    return nil, fmt.Errorf("FIREBASE_CREDENTIAL_JSON is empty")}opt := option.WithCredentialsJSON([]byte(json))app, err := firebase.NewApp(context.Background(), nil, opt)if err != nil {    return nil, xerrors.Errorf("Failed to initialize firebase app: %w", err)}client, err := app.Auth(context.Background())if err != nil {    return nil, xerrors.Errorf("Failed to get auth client: %w", err)}token, err := client.VerifyIDToken(context.Background(), idToken)if err != nil {    return nil, xerrors.Errorf("Failed to verify token: %w", err)}こんな感じです。実際のコードは以下にあります。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/api-server/grpc-server/util/auth.go#L24-L83検証が済んだらこの token に含まれるデータを信頼できるので、それを使ってユーザーの認証を行います。まとめFirebase Authentication を選んだ理由や基本的な認証の仕組みについて解説しました。明日は Firebase Authentication を実際のアプリケーションに組み込んだときに工夫した点や苦労した点について書きたいと思います。

Firebase Authentication を利用した認証

Adventarを支える技術 Advent Calendar 2019 の6日目です。今日は envoy の gRPC に関する便利機能について紹介しようと思います。gRPC-Web proxy4日目の記事でも書きましたが、今回は gRPC-Web の proxy レイヤーとして envoy を利用しています。envoy で gRPC-Web の機能を有効するのは簡単で、HTTP filters に envoy.grpc_web を書いて、ヘッダの設定をするだけです。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/api-server/envoy/envoy-prod.yaml#L44https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/api-server/envoy/envoy-prod.yaml#L36-L38これだけで gRPC-Web を受けて、upstream のクラスタに gRPC でリクエストするようになります。超簡単。他に書くことがありません。gRPC-JSON transcoder5日目の記事に書きましたが、Adventar では、gRPC と JSON API の両方を envoy によって実現しています。JSON API で受けて、upstream の gRPC に流すのは、envoy の gRPC-JSON transcoder という機能を使っています。https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/http/transcoder/v2/transcoder.protoこれは grpc-gateway と同じようなものです。Protocol Buffers の定義から生成したスキーマを envoy が読んで、gRPC をバックエンドにした JSON API を提供します。例えば、次のような Protocol Buffers を定義します。syntax = "proto3";package adventar.v1;import "google/api/annotations.proto";message GetCalendarRequest {  int64 id = 1;}message Calendar {  int64 id = 1;  string title = 2;  ...}service Adventar {  rpc GetCalendar(GetCalendarRequest) returns (Calendar) {    option (google.api.http) = {      get : "/v1/calendars/"    }  }}optionで指定しているのは、grpc-gateway でも使われているもので、 gRPC と JSON API のマッピングを定義するためのものです。envoy 側の設定は簡単で、envoy.grpc_json_transcoderを設定するだけです。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/api-server/envoy/envoy-prod.yaml#L46-L49ここで指定ているproto.pbは以下のようなコマンドで出力しています。$ protoc \  --include_imports \  --include_source_info \  --descriptor_set_out=../api-server/envoy/proto.pb \  adventar/v1/*.protohttps://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/protobuf/protoc.sh#L6-L10これで envoy と gRPC サーバーを起動すると、以下のようにアクセスすることが可能になります。$ curl http://localhot:8080/v1/calendars?id=1 | jq{  "id": 1,  "title": "xxx",  ...}クライアント側が gRPC を使えなくても、普通の HTTP で通信できるので、様々な場面で便利な機能だと思います。auto_mappinggRPC-JSON transcoder は便利なのですが、Protocol Buffers の定義にoption (google.api.http) = {  get : "/v1/calendars/"}のようなアノテーションを書かないといけないのが面倒です。これを解消するのに、envoy v1.11.0 から auto_mapping という機能が追加されました。https://github.com/envoyproxy/envoy/pull/6731これはgoogle.api.httpの定義を書かなくても、POST /<package>.<service>/<method>という URL でアクセス可能になるという機能です。設定は簡単でauto_mapping: trueと書くだけです。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/api-server/envoy/envoy-prod.yaml#L50これで以下のようにアクセスできます。$ curl -X POST -d '{"calendar_id":1}' https://localhost:8080/adventar.v1.Adventar/GetCalendar | jq{  "id": 1,  "title": "xxx",  ...}Adventar ではこの機能を使っているので、google.api.httpの定義は書いていません。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/protobuf/adventar/v1/adventar.proto（余談）google.api.http を捨てられていない理由google.api.httpの定義は書いていません、と言いつつ、実は一番下にgoogle.api.httpの記述があるのに気づいたと思いますが、これは gRPC サーバーの前に立てている AWS Application Load Balancer（ALB） のヘルスチェックが GET でしかできず、auto_mapping は POST にしか対応してないので、しかたなく書いています。ちなみに ALB は今現在 HTTP/2 の pass through に対応していないので、普通は gRPC の前段に置くことはできなくて色々と面倒なのですが、今回は gRPC-Web と JSON API しか通しておらず、直接 ALB が gRPC をしゃべる必要がないので ALB が利用できて便利です。このあたりのインフラの概要については後日書く予定でいます。明日は Firebase Authentication について書く予定です。

envoy の gRPC proxy に関する便利機能

Adventarを支える技術 Advent Calendar 2019 の5日目です。今日は gRPC-Web 導入にあたって最も苦労した Server Side Rendering（以降は SSR と書きます）の話を書きます。前提条件 初日の記事 に書いたとおり、今回の Adventar のシステム変更の目的に、gRPC-Web を使うServerless な仕組みで SSR をおこなうというのを入れました。趣味プロダクトなので技術が目的になっています。なので、gRPC-Web をやめる、SSR をしない、という選択肢はそもそも取らない、という前提で読んでください。（どちらかをやめることができればどれほど楽だったか...）また、ここでいう SSR とは Nuxt.js などで作った JavaScript のアプリケーションを同一コードでサーバー側でも動かして HTML をレンダリングする、という文脈のやつです。Universal JavaScript と言い換えてもよいです。個人的には SPA の SSR は実装難易度や運用コストが増えるので、やらないで済むならやらないほうがいい派なんですが、今回は普段やらないようなこともやってみるというのも目的の一つにありました。gRPC-Web が Node.js で利用できない問題gRPC-Web の自動生成したクライアントは完全にブラウザ用になっていて、Node.js では利用できません。何が困るかというと、SSR する際にブラウザとサーバーで同一のコードが使えないので詰んでしまいます。ブラウザ用の Polyfill などを入れてみたりしましたが、どうしても動かないので諦めました。正攻法は gRPC-Web のクライアント生成に手を入れて Node.js 用のトランスポートオプションをサポートすることだと思いますが、C++ （protoc の gRPC-Web プラグインの実装言語）が苦手すぎて今回は諦めました。そこで今回は妥協案として、Node.js 向けに JSON API を提供することにしました。JSON API というのは普通に ContentType: application/json で通信する API という意味です。つまりブラウザと API サーバー間は gRPC-Web で通信しますが、SSR する場合の Node.js と API サーバー間は JSON API で通信します。最悪な妥協策というのは理解しています。envoy を使った JSON API ProxyAPI を2種類用意するといっても、サーバーを別途を立てたわけではありません。gRPC-Web の proxy として利用している envoy に、JSON API を gRPC に変換する機能があるため、gRPC-Web と JSON API を同一のプロセスで処理できます。envoy のこの機能については後日詳しく紹介しますが、少し設定を足すだけで済むので、サーバー側は特に手間はかかりません。2つの API があることで面倒なのはクライアント側だけということです。クライアント側のコードクライアント側の対応はサーバー側よりは面倒ですが、そこまで複雑ではありません。以下のように gRPC のクライアントと JSON API のクライアントを用意します。gRPC ClientJSON API Clientそして以下のように ブラウザが実行する場合は gRPC、SSR の場合は JSON API を呼び出すだけです。gRPC の呼び出しmountedは SSR では呼び出されないのでクライアント側でしか実行されないJSON API の呼び出しprocess.serverは SSR の場合だけ true になるSSR は基本的に更新系のAPIを呼び出すことはないですし、今回は SSR するのをカレンダーの詳細ページ（ https://adventar.org/calendars/3860 のようなページ）だけに留めたので、最終的にはこれぐらいのコード量でなんとかなりました。しかしここに行き着くまでにはだいぶ苦労しました...。まとめ仕事だったらおそらく頑張って Node.js のトランスポートオプションを実装するか、gRPC-Web を諦めて JSON API に寄せるか、SSR を諦めて別の方法を取る道をさぐったかもしれませんが、今回は前提条件にもあるように、gRPW-Web と SSR は妥協できなかったのでこのような方法を採用しました。来年時間が取れれば gRPC-Web に Node.js サポートパッチを書きたいです。明日は envoy の便利機能について書く予定です。

gRPC-Web と Server Side Rendering の苦労話

Adventarを支える技術 Advent Calendar 2019 の4日目です。今日は gRPC-Web について書きます。gRPC-Web とはgRPC-Web は今年の10月に GA になったプロトコルで、今回の Adventar システムリニューアルでは絶対に gRPC-Web を production で使ってみる、という気持ちの元、 gRPC-Web を中心にその他の設計を決めました。gRPC は Google が公開している RPC 方式で、Protocol Buffers と HTTP/2 をベースにしたバイナリプロトコルです。ブラウザは HTTP/2 に対応していないブラウザもまだまだ現役でたくさんいますし、バイナリを扱うのが苦手だったりします。そこで、ブラウザでも利用できる gRPC-Web という新しいプロトコルを作り、gRPC-Web を gRPC に変換する proxy 層を介して通信することで、gRPC の旨味をブラウザでも利用できるようにする、というのが gRPC-Web です。gRPC の旨味というのは、Protocol Buffers による API スキーマの定義、そのスキーマを利用したクライアントの自動生成などが挙げられると思っています。grpc-gatewayを利用すると gRPC のサーバーとブラウザで通信することはできますが、Protocol Buffers の定義を使ったクライアントの自動生成などはできませんでした。proxy の実装は公式でいくつか提供されていますが、今回は envoy を利用しました。envoy 採用の理由は、gRPC-JSON transcoder などの機能も使いたかったためです。これについては後日の記事で解説します。実際に gRPC-Web でブラウザがどのような通信を行っているかは Chrome のコンソールなどで確認できると思います。リクエスト・レスポンスの body は Base64 なので読めないですが。TypeScript 対応今回 gRPC-Web を採用して一番よかったと思うところは、TypeScript のクライアント自動生成です。まだ Experimental な機能ではあるのですが、公式で TypeScript のサポートをしています。https://github.com/grpc/grpc-web#typescript-support実際に生成しているのは以下でhttps://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/protobuf/protoc.sh#L18-L21以下のように利用しています。https://github.com/adventar/adventar/blob/f580de20510f9debe6356a5ad193c4532d8f6a0d/frontend/lib/GrpcClient.ts自動生成されたクライアントを一段 wrap してアプリケーション内の型にキャストしているのがややダサいですが、これは実装し始めたときに PromiseClient というものが生えることに気づいてなくて、callback を Promise にキャストするついでに型変換も行っていた名残りだったりします。このように、TypeScript によるクライアントを自動生成することで、API のリクエスト/レスポンスの型が保証されるのは非常に良い体験でした。とはいえ、ハマったところや苦労したところも多々ありましたので、明日はそのあたりの話を書こうと思います。

gRPC-Web を利用したクライアント・サーバー間の通信

Adventarを支える技術 Advent Calendar 2019 の3日目です。今日はフロントエンドのフレームワークとして採用した Nuxt.js について感想を書こうと思います。個人的には Vue.js よりも React のほうが好きなので、最初は Next.js を検討しましたが、ルーティングまわりのできの良さ、エコシステム、全体の完成度などを吟味した結果 Nuxt.js を選択しました。Next.js が全然ダメというわけではないので、好みにもよると思います。ここがよかった Nuxt.jsオールインワンな環境ビルドや Lint の環境が自動できて、テストのライブラリや State 管理の仕組みも組み込まれていて、デプロイもコマンド一発で簡単にできる環境がすぐに整うのはよかったです。小さいライブラリを自分で組み合わせて作るのもいいですけど、Webフロントエンドの技術スタックは選択すべきものが多すぎるので、何も考えずに Nuxt.js が勧めてくるものを脳死で使うというは楽です。このあたりはおそらく Next.js も大差ないですね。エコシステムプラグインやドキュメントが豊富なのはよかったです。Nuxt PWAなどは少し設定するだけで PWA の設定ができたり、nuxt-fontawesomeでパっと fontawesome が導入できたりとか。View のコンポーネントライブラリについても Vue.js のライブラリが利用できるので、欲しいものはだいたいあるので良いですね。個人的に UI コンポーネントはよほど面倒なものじゃない限り自作するのが好きなので今回はほとんど使いませんでしたが。ルーティングNext.js との比較になりますが、ルーティングの機能はよくできていると思います。特に動的なルーティングに大きな違いがありました。Adventar はもともと Rails でできていたので、/calendars/:id のような URL になっていました。これを Next.js で表現しようとすると、/calendars?id=100のようにするか、express などのサーバーを置いて処理するしかありませんでした（つまり SSR 必須）。Nuxt.js では、以下のようなディレクトリ構成にするだけでこのルーティングを express などのサーバーを建てずに実現できます。.└── pages    └── calendars        └── _id # アンダースコアから始まる名前は動的な値を指定できる            └── index.vueただ、この機能は Next.js にも少し前に入りました。https://nextjs.org/blog/next-9#dynamic-route-segments実際に試してはいませんが、これがあったら Next.js を採用していた可能性はあります。しかし、動的なルーティングのファイル名の規則が、Nuxt.js が _id のようにアンスコで始まる、というものに対して Next.js は [id] のようにブラケットで囲む、というものでありだいぶ気持ち悪い感じはありますね...。ここは微妙だった Nuxt.jsTypeScript対応TypeScript  対応に苦労しました。今は公式で対応しているので難しくないと思いますが、作り始めたころは絶賛 TypeScript 対応中という感じで、試行錯誤した覚えがあります。また、これは Nuxt.js というよりは Vue.js の問題なのですが、TypeScript の型チェックがテンプレートに効かないので、結局テンプレートのところで型の齟齬が発生してエラーになることがあってせっかくの TypeScript が片手落ちという感じでした。Vuex と TypeScript の相性もアレですし。Vue.js もそのうち改善されるとは思いますが、この点においては React のほうが圧倒的に好きです。バージョンアップNuxt.js を 2.8.1 -> 2.10.1 にあげたんだけど全然動かなくてセマンティックバージョニングとはいったい... という気持ちになってる— hokaccha (@hokaccha) 2019年10月14日つらい。けっきょくまだバージョンアップできてません。まとめ総合的には Nuxt.js はよくできているフレームワークで、採用してよかったと思いました。ただやはり個人的には TypeScript との相性の面で React のほうが好きなので、Next.js に期待したいところです。明日は gRPC-Web について書きます。

Nuxt.js によるフロントエンドの構築

Adventarを支える技術 Advent Calendar 2019 の2日目です。Adventar はオープンソースでコードを公開しているので、誰でも環境を再現することができます。ただ、システムがそこそこ複雑で、ドキュメントなども全然書いていないので、たぶんリポジトリを見ても起動する方法がわからないと思うので、自分用のメモも兼ねて Adventar をローカルで起動して開発する方法をここに記しておきます。まずソースコードを手元に持ってきます。$ git clone https://github.com/adventar/adventar$ cd adventarソースコードのディレクトリ構成は次のようになっています。$ tree -L 1.├── README.md├── api-server    # API server├── batch         # スケジュール実行されるバッチジョブ├── db            # database のスキーマ├── frontend      # Nuxt.js によるフロントエンド（SSRのコード含む）├── image-server  # 画像サーバー├── protobuf      # protocol buffers の定義└── terraform     # インフラ構成のコードbatch, image-server , terraform, protobuf あたりはローカルで起動するのには使わないので今回は気にしないでください。まず認証で使っている Firebase Authentication に必要な Credentials を作る必要があります。これがなくても起動はできますが、ログインができないのでカレンダーの作成や登録ができなくて、実質なにもできません。Firebase Consoleで新規プロジェクトを作り、Googleログインに設定を有効にします。次にサービスアカウントの設定から秘密鍵の生成を実行します。そうするとJSONファイルがダウンロードされるので、これをAPIサーバーの起動時に環境変数に設定します。$ export FIREBASE_CREDENTIAL_JSON=$(cat ~/Downloads/adventar-test-firebase-adminsdk-xxx.json)$ cd api-server$ docker-compose upこれでAPIサーバーは起動するはずです。環境変数の設定は毎回やるのは面倒なら direnv や envchain などを使うといいと思います。僕は envchain を使っています。これだけだとまだ DB に table ができていないのでスキーマを流します。$ cd adventar/db$ mysql -u root -h 127.0.0.1 --port 13306 adventar_dev < schema.sql最後にフロントエンドのサーバーを起動します。フロントエンドのサーバーにも Firebase の環境変数をいくつか設定する必要があります。$ export FIREBASE_API_KEY=xxx$ export FIREBASE_PROJECT_ID=your-project-name$ export FIREBASE_AUTH_DOMAIN=your-project-name.firebaseapp.com$ cd adventar/frontend$ yarn install$ yarn devFIREBASE_PROJECT_IDは先程ダウンロードした JSON に記述されているproject_idです。$ cat ~/Downloads/adventar-test-firebase-adminsdk-xxx.json | jq .project_idなどで確認できると思います。FIREBASE_AUTH_DOMAINは project id に.firebaseapp.comを付け足したもの、FIREBASE_API_KEYはFirebaseの設定画面から確認できるはずです。これで http://localhost:3333/ をブラウザで開いてログイン、カレンダーの作成などができるはずです。明日は Firebase Authentication についてもう少し詳しく書こうと思います。

Adventar をローカルで開発する

Adventar を支える技術 Advent Calendar 2019 の1日目です。Adventar はサービスを開始した2012年以来、Rails を利用してサービスを提供してきました。今年はそのシステムを一から設計し直し、以下のような技術要素を使って実装しました。Nuxt.js による SPA なフロントエンドGo で gRPC の API サーバーgRPC-web によるクライアント/サーバー間通信Firebase Authentication による認証envoy で gRPC の proxyAWS Lambda による Nuxt.js の Server Side RenderingTerraform による AWS リソースの管理Serverless Framework による AWS Lambda, API Gateway のデプロイAmazon ECS, Fargate を利用した API サーバーのホスティングLambda と CloudWatch Events を利用した定義ジョブLambda と API Gateway を使った画像のリサイズサーバー他にも色々ありますが、概ねこんな感じです。また、今年からソースコードをオープンソースにしました。技術選定について細かいところは追々説明するとして、今回はなぜこういう技術を選定したのか、について書こうと思います。実装する前からわかっていたことではあるのですが、これぐらいのサービス（tableは3つ程度、トラフィックも小規模）でこのような構成にするのは完全にオーバーテクノロジーで、私が一人で開発する前提であれば Rails で実装して Heroku でホストするのが実装コストも運用コストも絶対に安く済みます。今回このようなオーバーテクノロジーな構成を選択したのは完全に個人的な学習目的であり、この規模でこのような構成を選択することはオススメしないということを一番最初に断っておきます。今回の構成にするのに、最初から今の構成に決めて実装したわけではなく、最初に決めたのは、フロントエンドとサーバーサイドは実装を分けて、次の2つを使うということだけです。gRPC-webサーバーレスな環境（AWS Lambda や Google Cloud Functions）で Server Side Rendering理由としては、個人的に学びたいと思っているけど直近で利用する機会がなさそうなので、個人サービスで実験的に導入して試してみたいというのが大きいところです。その他の構成要素はこれらを軸に実装していく上で、比較検討しながら決めていきました。Nuxt.js（フロントエンドのフレームワーク）Next.js か Nuxt.js の2択だったVue.js よりは React のほうが好きだが、フレームワーク的に Nuxt.js のほうがよくできていそうだったGo（gRPC Server）Ruby は仕事でも使っていてお腹いっぱい気味なので別の言語にしたいgRPC サーバーで安定した実装が提供されているのは Go or Javago と Java の知識は同程度（ほぼない）が Go のほうを学びたいECS/Fargate（API サーバーのホスティング）gRPC をホストしないといけないので Heroku は使えないKubernetes を試してみたい気持ちはあったが自前にしろマネージド（EKS, GKE）にしろ学習コスト、運用コストが高い、マネージドだと料金も高い適当な VPS や EC2 で systemd とかで運用するというのも考えたが自前でサーバーを管理したくないので多少コストはかかるが ECS, Fargate を選択Firebase Authentication（認証サービス）対抗は AWS Cognito、Auth0、自前でがんばる自前はめんどくさいので最後の手段Cognito は要件を満たしてない、Auth0 はお金かかりそう、ということで  Firebase AuthenticationCloudFront（CDN）対抗は Fastly金額などの面で CloudFront を採用（詳しくは後日）AWS Lambda（FaaS）色々決めていくうちに AWS によってきたので  Google Cloud Functions でなく AWS Lambda にした。あまり比較検討はしていないServerless Framework（Lambda のデプロイツール）AWS SAM との比較になったほぼ変わりなかったがプラグインが豊富にありそうだったので選択Terraform（AWS のリソース管理）特に考える余地なし（対抗は CloudFormation ぐらい？）だいたいこんな感じです。選定の基準としては技術的チャレンジの有無金銭的コスト時間的コスト（学習コスト、実装コスト、運用コストなどを含む）ユーザー体験あたりのバランスを考えながら選んでいます。例えば時間とお金が無限にあれば、Kubernetes を使ってみたり、普段利用している AWS でなく GCP をフル活用してみたかったですし、何も技術的チャレンジをしないなら Rails, Heroku が一番コスパがいいのはわかっていました。細かい話しはもっと色々ありますが、あと24日あるので後に譲ることにします。明日は Adventar をローカルで起動する方法について書きます。