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-1
2016年
軽微な変更のみで大きな変更はなかったみたいです。
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を支える技術 Advent Calendar 2019 の23日目です。
今年から Adventar はオープンソースにしました。
ツールやライブラリ、言語などのソフトウェアであれば今の時代オープンソースというのは山程ありますが、サービスがオープンソースというのはそんなに多くないと思うので今回はそうした理由や、いい点、悪い点などについて書こうと思います。
オープンソースにする理由
特にクローズドである意味もないので、オープンソースにしたいとは前々から思っていて、昔のコードはオープンにしづらい履歴もあるし、システムリニューアルのタイミングでちょうどいいので、このタイミングでオープンにしました。
オープンソースにして誰かの役に立てば嬉しいし、誰かが勝手にバグを直したり機能改善をしてくれるかもしれないし、Fastly や AWS などはオープンソース支援で料金を補助してくれたりするし（試しに申請してみる予定）、いいことばっかりです。
- https://docs.fastly.com/en/guides/accounts-and-pricing-plans#free-open-source-developer-accounts
- https://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 などがそうです。
これらのサイトはオープンですが特にそれを使って類似サービスがでたりはしてないし、心配するだけ無駄だと思っています。
まとめ
今日はサービスをオープンソースにして開発する意味や懸念点について書きました。明日は Adventar の歴史について書こうと思います。
細かすぎて伝わらない UI の工夫
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 でやっていてもう少し複雑ですが、こんな感じのイメージです。実際のコードは以下です。
これでさっきの画面は以下のようになります。
だいぶマシですね。
部分的にローディング
API の呼び出し待ちなどにローディングを表示するのはユーザーに状況を伝えるのに重要なアクションですが、ローディングを表示するのはできるだけ小さい範囲に留めるようにしています。
例えばトップや検索画面のカレンダー一覧ですが、カレンダーの一覧取得には API の結果を待たないといけないので、返ってくるまでしばらくラグが発生します。そのとき全画面ローディングにしてもいいのですが、以下のように、必要な部分だけをローディングにすることで、可能な限りユーザーに速く画面を見せます。
また、8日目の記事に書いたのですが、最初のログイン処理にやや時間がかかってしまうため、その間ローディングを出したいのですが、これもログイン情報が必要なところは多くないので、必要なところだけローディングにして体験を損ねないようにしています。
これでだいぶ初期表示が速くなり、体験がよくなります。
吹き出しの位置のこだわり
これは本当に細かいのですが、カレンダーで登録情報を編集するポップアップがあるのですが、この吹き出しの位置に微妙なこだわりがあって、端の登録を押したとき、スマホなどの画面幅が狭い場合は以下のようになります。
可能な限り選択した吹き出しに近い位置に出して、吹き出しの三角は選択したセルを指します。
また、PC などの画面幅が広いデバイスで見た場合は左右に余白ができるので、端のセルでも中央にポップアップを表示したいところです。
書いてみると当たり前の動きな動きすぎてなんでこれを紹介しているのか自分でもよくわからなくなってきましたが、この動作をあらゆる画面幅で動作するように実装するのが思いの他大変だったので紹介したくなっただけです。
実装を見返してみると色々ハードコーディングしてあったりして泥臭くてだいぶひどい感じですが、がんばった後が見られますね...。
まとめ
今日はネタ切れ気味で細かい UI の話を書きました。本当に細かすぎてすいません。明日は Adventar をオープンソースで公開した話を書こうと思います。
View のモバイル対応
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パターンに絞りました。
| サイズ | 幅 |
|---|---|
| Small | width < 576px |
| Medium | 576px <= width < 768px |
| Large | 768px <= width |
Small
Medium
Large
モバイルファーストで作る
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 の工夫について書こうと思います（ネタ切れです）。
Bugsnagを利用したエラートラッキング
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 },
今回エラーハンドリングには xerrors を使っているのですが、xerrors で wrap したエラーを投げると、bugsnag 上でのエラーが全部 *xerrers.Wrap になるの困っています。どうにかしたいのですが、エラーの量もそこまで多くなくて困らないので放置しています。
また、スタックトレースの情報がわかりづらく、例えば以下のエラーは
以下の箇所で発生していますが、entry.go:118 がスタックトレースに表示されません。
この問題はメタデータとして、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 を使えばこのあたりでやってくれます。
とりあえず最低限の情報だけ詰めて対応しました。
app.use((err, req, _, next) => { const opt = { request: { headers: req.headers, httpMethod: req.method, url: req.url } }; // このコールバックでエラー送信の終了を待つ bugsnagClient.notify(err, opt, () => { next(err); }); });
また、もう一つの問題は source maps です。
https://docs.bugsnag.com/platforms/javascript/source-maps/
ブラウザの JS であれば、sourceMappingURL に書いてある URL に取りに行ってくれるので便利ですが、Node.js の場合は source maps のファイルを別途 Bugsnag にアップロードする必要があります。がんばればできそうですが、今回はめんどうなので諦めました。いつかやるかもしれません。
まとめ
今回は Bugsnag を導入するのにはまったことなどを書きました。実際 Bugsnag はかなり役に立っていて、Bugsnag のおかげでいくつかのエラーを特定して潰すことができました。いくつか中途半端になっているところがあるので今後改善していきたいと思います。
明日は UI のスマホ対応について書きます。
SSR の CDN によるキャッシュ戦略
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-accounts
CloudFront によるパージ
まず、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 によるエラートラッキングについて書きます。
インフラコストの最適化
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 に設定しました。
これがデフォルトの 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/month
- EC2(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 に刺すようにしました。
この Security Group は terraform で管理せずに手積みで管理しています。
