GraphQLとFargateやめました

研究室HPを公開して3年数ヶ月が経ちました。これまでに色んな人が記事を公開してくれて記事総数は100件を超えています(100回目の記事)。検索上位に出てくる記事もチラホラあるので研究室のHPとしては日本でも有数のコンテンツクオリティではないでしょうか。

正直1年ほどで打ち捨てられるものだと思っていたのですが、案外もってくれたという印象です。

さて、ここ最近このシステムがあまりうまく動かないことが増えてきていました。いつかはこうなると思っていたので耐用年数が来てしまったのかなという所感です。

問題として報告されている箇所を修正すればまだ騙し騙し同じシステムを使っていけるとは思いますが、所々の理由で設計から見直してすべて作り直ししました。

要件

システムのリプレイスなので「以前と同じ動作をする」ことが基本的な要件になります。

既存動作の仕様は以下に示すようなものです。

• Slack Botで記事を投稿、編集などできる
• Slack Botで画像のアップロードもできる
• トップページの各項目もSlack Botから更新できる

基本的に**「Slack Botで全部できる」**が仕様となります。Slack Botに話しかけると記事が作成されてその記事がhttps://moriokalab.comで見られるようになります。

実際に動いているSlack Botはこんな感じで動いています。

インフラ的な構成はこんな感じでした。DynamoDBにデータを保存してました。

問題点

全部作り直しをするにあたって要因となった原因が2つあります。

1. 尖った構成で引き継ぎコストがとても大きい
2. AWSの費用が高い

1. 構成が尖っていた

• 研究室のHPをサーバレス、SPA、GraphQL、ChatOpsで作った
• このHPの動作環境をLambdaからECS Fargateに移行

この2つの記事を見るとわかると思うのですが、研究室HPはかなり尖った構成で動いていました。

引き継ぎ資料はなるべく手を動かせる形でまとめてはいたのですが、やはりWeb開発の初手がGraphQLサーバーにFargateで動くフロントエンドというのはあまりにも酷という感想です。

実際、アプリケーションが壊れてから1ヶ月以上修正されず放置されていました。

ここで、もう少し創意工夫を廃してプラクティスに則ったググりやすい構成に直すほうが他の人も触りやすくなるはずと判断しました。

2. AWSの費用が高い

上の記事にあるように、インフラに一部AWS ECSのFargateを使用していました。ベストプラクティスに従うとPrivate VPCにタスクを置いてNAT Gateway使って外のネットワークに通信する方式なのですが、こうするとNAT Gatewayが思ったより高くて月に$200ほどかかってしまいます。年間$2400。他のインフラもあるので日本円にすると年間合計50万円程度がAWS代になっているわけです。

さすがにこれを放置するのはよろしくないのでカットできるコストはなるべくカットすべきだと判断しました。

品質特性

作り直しに際して、どういう仕様や制約が存在するのかを考えてみます。

ざっくりとした品質特性はこんな感じです。

特性	内容
機能性	Slackから記事を投稿、編集できる
機能性	ドメイン名はmoriokalab.comで変えない
機能性	OGPの設定などSEO対策が行われている
機能性	記事の検索が行える
使用性	1000ms以内の応答
信頼性	SLO等は特に定めないが、障害時にはなるべく早く切り戻せる
保守性	メンテナンスフリーが必須
保守性	デプロイは楽に行われなければならない
保守性	なるべく低いインフラ費用での運用
保守性	なるべくシンプルな作りにする
移植性	今後他のメンバーが別の言語で作り変える可能性がある

特に重要なのがSlackから更新、メンテナンスフリー、低いインフラコスト、作り直しの容易さ、の3つです。

技術選定

さて、上記の品質特性と要件に応じて改めて技術選定をします。

選択肢はいろいろあって試行錯誤もあったのですが結論だけ書いておきます。

• APIサーバー
  • OpenAPIでREST APIのスキーマ定義
  • OpenAPIスキーマを使ってGoでAPIサーバー
  • HerokuにAPIサーバーをホスト
  • HerokuのPostgreSQLを使う
• フロントエンド
  • Next.jsでフロントエンドを構築
  • OpenAPIスキーマを使ってAPIクライアントを生成
  • Vercelにフロントエンドをホスト
• Slack Bot
  • TypeScriptとBoltでSlack Botを作成
  • Serverless FrameworkでAPI GW/Lambdaにホスト

構成要素は以前の構成と変わらず3要素で、APIサーバー、フロントエンド、Slack Botです。

OpenAPIでスキーマ定義することでAPIクライアントのコピペミスなどを防げますし、サーバー側はこのスキーマを使って別言語で書き直すこともできます。

ホスト先については基本的にメンテナンスフリーかつ安価なものを探した結果HerokuとVercelに落ち着きました。Herokuは案外制約が多かったのでまた別のホスティングサービスを探してもいいかなと思いました。

費用概算

上記のインフラで動作するシステムの月額費用は以下のようになります。

• Heroku: $25/月
• Vercel: $20/月

基本的に$45/月で運用できる想定です。0円が目標だったのですがさすがに無理でした。結構安くなったのでまあ許容範囲内でしょう。

まとめ

開発担当は去年3月に修了したOB(1)です。興が乗ったため手を動かしたのですがOBがあんまりやるのもな、とは頭の隅で思ってます。

きっと耐用年数は増えたのであと5年くらいはメンテナンスフリーで動いてくれるはずです。