インフラコストの最適化
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 で管理せずに手積みで管理しています。
まとめ
Adventar のインフラコスト
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: $5
- Route53: $3
- データ転送量: $3
- CloudWatch: $1
といったところです。
RDS や ALB、Fargate については、このぐらいかかると見込んでいたので予想通りでした。思ったよりもかかっていたのが CloudFront と API Gateway です。これらはリクエスト数がもろに料金に反映されます。アクセス数と料金の変異を見るとばっちり一致します。
アクセス
料金
なので、ピーク時期がすぎればもう少し落ち着いて、コスト的には半分ぐらいで落ち着くのではと思っています。逆に、そうなってくると Fargate や RDS などの、常時起動しておく必要があるリソースのほうが支配的になってくるはずです。
また、S3 や Lambda はヘビーに使っているにも関わらず、ほぼ無料で使えているのもわかります。
まとめ
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.html
S3 の設定は簡単で、これだけです。
http だけであればこの bucket にエイリアスレコードを設定すれば終わりですが、httpsも対応したいので、CloudFront に ACM の証明書を刺して https も受けられるようにしています。
img.adventar.org
画像のリサイズサーバーです。詳細は以下に書きました。
上記の記事でも書いたとおり、DB や API サーバーに依存しないので、構成をシンプルに保つことができます。
adventar.org
ユーザーフェイシングな HTML や静的ファイルのリクエストを受けます。詳細は以下に書きました。
図にもあるように、SSR をしている Lambda が API サーバーへリクエストしています。このリクエストは本来は VPC 内部で Lambda を起動して内部通信するのがいいのですが、めんどくさいのでインターネット経由になっています。
api.adventar.org
API サーバーです。VPC の中に配置した ALB がリクエストを受けて、その後ろにいる ECS がいて、ECS では Fargate でタスクがいて、Envoy と Go による gRPC のサーバーが動いています。DB は同じ VPC に配置されている RDS です。gRPC や Envoy の話は以下に書きました。
バッチジョブ
VPC の中にいる CloudWatch Events と Lambda は、定期実行されるバッチジョブです。詳細は以下に書きました。
まとめ
Adventar の AWS の構成についての概要を書きました。明日はインフラのコストについて書こうと思います。
schemalex による DB のスキーマ管理
Adventarを支える技術 Advent Calendar 2019 の15日目です。
今日は DB のスキーマ管理について書きます。
Rails の DB マイグレーションと Ridgepole
Adventar は昨年まで Rails で作っていて、DB の マイグレーションも Rails デフォルトの機能を使っていました。Rails の DB マイグレーションは、それなりによくできてはいますが、差分を積み上げていくので大量のマイグレーションファイルができて煩雑になる、多人数での開発の場合にコンフリクトしやすいなど、いくつか問題があります。
個人的にはこういった問題もあるので、Ridgepole のように DB のスキーマ定義だけを管理し、現在のスキーマとの差分を計算して ALTER 文を発行してくれるような仕組みのほうが好きです。
最初は Ridgepole を使おうと思ったのですが、API サーバーは Go で書こうと思っていたので、スキーマ管理のためだけに Ruby 依存を入れるのは微妙かな、と思い他のツールを検討しました。
schemalex と sqldef
Go 製の Ridgepole 的なツールは
の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.sql BEGIN; 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 でも十分そうということですね...！）
まとめ
Lambda を使った画像のリサイズサーバー
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行ちょっとの簡単なものです。
いくつか工夫していているとこがあるので説明します。
DB に依存させない
まず、一つ目が DB に依存せずに動作させるということです。画像の URL は、DB に保存されていますので、画像 URL を知るためには、カレンダーの投稿 ID を受け取って DB にアクセスし画像 URL を取ってくる、ということが必要になりますが、そのためだけに DB にアクセスするのはめんどくさいので、今回はリクエスト URL に直接画像の URL を埋め込んでいます。
https://img.adventar.org/?url=<画像URL>
のような感じです。Lambda でこの画像 URL を fetch して、適当なサイズにリサイズして返します。本当はサイズの指定もクエリでできるようにしたいのですが、とりあえず今は1サイズしかないので固定にしています。
ハードコードでだいぶひどい感じですが、かなりギリギリになって実装したので雑コードです（投稿が始まる12月までにあればいいので実装を一番最後に回した）。
ダイジェスト値による検証
ただ、これだと任意の URL のプロキシになってしまってよろしくないので、ダイジェスト値を設定して URL が改ざんされていないかを検証しています。OSS なのでコードを読めばわかりますが、単に画像 URL に SALT を混ぜて sha1 を取っているだけの簡単なものです。なので最終的な URL はこのような感じになっています。
https://img.adventar.org/img/<digest>?url=<画像URL>
実際の URL はこんな感じです。
デプロイ
フロントエンドのデプロイ や バッチジョブのデプロイ にも利用した Serverless を利用しました。今回 Serverless 大活躍です。設定はこんな感じで何も難しくない。
デプロイスクリプトも
$ serverless deploy
で終了。
まとめ
Lambda を使った画像のリサイズサーバーについて書きました。明日は DB のスキーマ管理について書きます。
Lambda と CloudWatch Events を利用した定期ジョブを Serverless で管理する
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 にアクセスしてメタデータを取ってくる、というジョブを動かしたいのです。
ジョブのプログラムは簡単で、こんな感じです。
CloudWatch Events と Lambda
今回は常駐するサーバーがないので cron を実行する環境がありません。いくつか方法はありますが、CloudWatch Events を使うことにしました。CloudWatch Events は cron のような書式で定期的に何かの処理をトリガーすることができるので、今回はこれを利用します。
CloudWatch Events のトリガーには様々なものが設定できますが、今回のケースは、Lambda か ECS tasks でプログラムを実行するのがよさそうです。
どちらでもよかったのですが、Lambda であれば Serverless フレームワークを使って管理することができそうだったので、今回は Lambda で実行することにしました。
追記: これを書いた後で諸事情により ECS に変更したので、現在は ECS で動いています。
Serverless を使った設定
特に難しいことはなくて、以下のような設定を書くだけです。
これで 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 を利用した画像のリサイズサーバーについて書きます。
ecs-cli を利用したAPI サーバーのデプロイ
Adventarを支える技術 Advent Calendar 2019 の12日目です。
今日は API サーバーのデプロイについて書きます。
API サーバーは、4日目の記事 でも書いたように、gRPC のサーバーをたてています。この API サーバーは、Amazon ECS, Fargate を利用してホストしています。
ECS のデプロイツールは色々とあって、仕事で使っているのは hako というツールです。今回は他のツールも使ってみたいというのもあって、AWS 公式が提供している ecs-cli を使ってみました。
https://github.com/aws/amazon-ecs-cli
ecs-cli の他の良い点としては、docker-compose.yml を設定ファイルとして使えるというところじゃないかなと思っています。docker-compose.yml であれば、ツール独自のシンタックスを覚えなくても良いのがいいですね。
ただ、当然のようにdocker-compose.yml だけでは足りなくて、ECS 独自の設定も別途必要になります。それはecs-params.ymlという設定ファルに書くのですが、設定ファイルが分散してしまうのが微妙という見方もありそうです。
Adventar ではそれぞれ以下に設定があります。
ecs-cli のコマンド
compose create service
https://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/xxx
compose service up
https://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 scale
https://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 2
docker push
デプロイする際は、ECS のデプロイの前に docker push する必要があるので、git の HEAD の revision で tag を打って dockdr push してからデプロイしています。こんな感じです。
TAG=$(git rev-parse HEAD) cd $ROOT_DIR/grpc-server docker build -t hokaccha/adventar-grpc-server:${TAG} . docker push hokaccha/adventar-grpc-server:${TAG} cd $ROOT_DIR/envoy docker build -t hokaccha/adventar-envoy:${TAG} . docker push hokaccha/adventar-envoy:${TAG}
今回はコードもオープンですし、ECR は利用せずに Docker Hub の public なところに push しています。
実際のデプロイスクリプトはこんな感じです。
まとめ
API サーバーを ECS でデプロイする話しを書きました。明日は Lambda と CloudWatch Events を使った定期ジョブについて書きます。
