北海道新型コロナウイルスまとめサイトのインフラ構成(リリース時)

プログラム全般

前回の記事「東京都新型コロナウイルス感染症対策サイトをforkしてnetlifyでdev環境を立ち上げる手順」はたくさんの方に見ていただいているようなので続編です。

今回は、「北海道新型コロナウイルスまとめサイト」のインフラ構成がリリース時どのようになっていたか(今は少しバージョンアップしています)の説明です。

北海道 新型コロナウイルスまとめサイト
当サイトは、道内の新型コロナウイルス感染症(COVID-19)に関する最新情報を提供するために作成されました。開発は、ICTエンジニアやデザイナーなどによって結成された「JUST道IT」が行っています。 複製・改変が許されたオープンソースライセンスで公開されている、の仕組みを利用しています。

前提

説明すること

  • インフラ構成
  • ブランチ運用
  • 運用開始後の所感

インフラ構成

こうです!シンプル!

  • GitHub内でGitHubActionsを使って静的ファイルを吐き出す仕組みは「東京都対策サイト」の仕組みをそのまま。(前回の記事参照)
  • stagingは運用しない。dev環境と本番環境だけ。
  • サーバはさくらのクラウド1台のみ
    • nginxのvirtualhostで環境を切り分け
    • 2コアメモリ1GB
  • サーバからcronで5分に1回`git pull`して自動更新
  • 本番環境では、ウェブアクセラレータ(CDNサービス)を使って負荷対策

ほぼ最小構成なんじゃないかな、と思います。

ブランチ運用

  • developmentとmasterの2ブランチ運用が軸
  • 一般的なPR運用で、developmentにPR、merge
  • コードはほとんどレビューしてない感じ
  • なんとなく合意がとれたタイミングでdevelopment->masterにPR -> merge
  • 仕様はissueメイン、たまにSlackで議論

流れ自体は一般的なものですが、明確なリーダーや責任者を置いている組織(集まり?)では無いため、レビューやリリースについては結構ふんわりしています。

でもちゃんとリリースできたし、運用もしてるのですごいですね。

運用開始後の所感

サーバのスペックは弱めでスタートなので心配でしたが、ほとんどのアクセスをウェブアクセラレータがさばいてくれるため、サーバ自体の負荷は無風でした。

これくらい無風でした。

top - 12:22:47 up 1 day, 16:19,  3 users,  load average: 0.04, 0.05, 0.00
Tasks:  94 total,   1 running,  59 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.2 st
KiB Mem :  1008676 total,   165324 free,    91524 used,   751828 buff/cache
KiB Swap:  4194300 total,  4194032 free,      268 used.   745644 avail Mem

Nuxtを使って静的ファイルを置くだけ、という構成の作戦勝ちだと思います。

「北海道まとめサイト」ではさくらインターネット株式会社様のご好意もあってサーバを普通に立てていますが、静的ファイルのホスティングさえできれば良いため、環境の選択肢が多くある & 環境構築が簡単です。

料金面をおいておけば、東京都のようにNetlifyでも良いですし、AWSのS3やGCPのCloudStorageでも良いわけです。

また、ほとんど何も考えずに手前にCDNをおくだけで、さらにパフォーマンスもあがります。

これがサーバサイドでHTMLを生成する仕組みだと、負荷はもっと高くなりますし、環境構築も手間が増えます。

まとめ

こんなシンプルな構成で動いてるんですよ、という紹介でした。

これでいけてるのは、静的ファイル配信するだけ、という構成になっているからですね、、、

東京都対策サイトがどこまで考慮していたかはわかりませんが感謝です。

次回は、実際のアクセス数等を見つつ、Netlifyの100GB制限について検証してみようと思います。

コメント

タイトルとURLをコピーしました