webshのインフラをさくらVPSから別環境に変更できないか調査
理由はAWSを業務で使っているので、その勉強がてら これをもう少し安くできるのでは、と考えている
なぜなら、webshはサーバが常時起動しているけれど、リクエストが来てる時間や量はめちゃくちゃ少ない(たぶん) リクエストが少ないなら上記サービス等を使ったほうが安くなるのでは、と考えている
前提
https://gyazo.com/adf712d397fb6d569e12a5ca367f2275
code:plantuml
@startuml
actor User as u
participant Nginx as nginx
participant アプリ as app
participant シェル芸Bot as shell
u -> nginx : 画面表示
nginx -> u : HTMLを返却
u -> nginx : APIリクエスト
nginx -> app : シェル芸実行
app -> shell : シェル芸Botコンテナを起動して実行
shell -> app
app -> nginx
nginx -> u : レスポンス
@enduml
この時、アプリは3GBのシェル芸Botイメージを使ってコンテナを起動している
リクエストの都度docker pullするわけにもいかないので、サーバ上でdocker pullしておいてキャッシュしている
シェル芸の実行は都度環境を初期化する必要がある
他の人の実行結果がファイルシステム上に残ってはいけない
なので、都度コンテナを作成、破棄しなければならない
ホスト側でDockerAPIを使えるようにしていて、アプリコンテナからはAPI経由でコンテナを起動している このAPIはサーバ上からしか実行できないようにポートを閉じている
インターネットから直接呼び出すことはできない
アプリコンテナはDocker in Dockerしていない
問題点
前提に書いたとおり、アプリコンテナからDockerを操作できる必要があって、これが既存のPaaSに移行できない理由になっている
もしコンテナだけでやるのであればシェル芸Botコンテナを複数台常駐させる形になりそう
https://gyazo.com/a08ff124dd37f1ba54faa28c0380f5fc
code:plantuml
@startuml
actor User as u
cloud AWS {
package Fargate {
}
}
u -do-> app
app -do-> s1 : どれか1つ動いてるやつにリクエストを出す
app -do-> s2
app -do-> s3
app -do-> s4
app -do-> s5
@enduml
1台常駐だと、シェル芸実行→コンテナ再作成の待ち時間が長くなる
待ち時間を減らすには、常駐コンテナを複数用意しておいて、処理が終わったら破棄。空いてるコンテナが次のリクエストを受付、のような構成になる
ただしこの構成にするとランニングコストが確実に跳ねる
妥協案
これは受け入れて、運用コストの削減の方にフォーカスして考える
OSのアップグレードやパッケージの更新をSSHで繋いでコマンドを叩いてやる必要があって、これの敷居が高い
なぜならば、サーバが一台しかないから
更新に失敗したらそれなりに長い時間アプリが停止する
更新のときだけサーバを追加で調達する、ってのもありだろうけれど、僕の記憶ではさくらVPSのサーバ調達にはEC2よりだいぶ時間がかかる 1日くらいかかったかも
EC2なら必要なときに追加、が気軽にできるし、従量課金なので相性も良い
ということでEC2でどれくらいのランニングコストになるかを考える
現状
メモリ1GB、サーバ1台、月990円
EC2構成にするならば
https://gyazo.com/937e296a86d8d2fc05e200c2e2046db1
code:plantuml
@startuml
actor User as u
actor Developer as dev
cloud AWS {
database S3 as s3
node EC2 as ec2 {
}
database ECR as ecr
node CodeBuild as build
}
u -do-> cf
cf -do-> s3
u -do-> app
dep -do-> ecr : docker pull
eip -> ec2
eb -up-> build : 日次で実行する
build -> hub : docker pull
build -up-> ecr : docker push
dev -do-> gh : git tag
dep -do-> gh : 新しいタグを監視。\n更新があれば自身でデプロイ
dep -> s3 : 静的ファイル更新
dep -> cf : invalidation
@enduml
EventBridge + CodeBuildで日次でシェル芸Botのイメージを取得してECRに保存
直接DockerHubにイメージを取りに行くのだとデータ転送課金に響く
非同期にイメージを取りに行って、ECRに保存しておく
ECRはGBごとに0.1ドル。タグを分けて保存しないので、3GB保存
EC2を1台稼働
t4g microで足りるはず
EC2ユーザデータを使って、サーバの起動時にプロビジョニングを行う
こうすればミドルウェアのアップグレードは再起動時に行われる
OSをアップグレードしたくなったら、AMIを新しいものに変更してEC2を起動するだけでよくなる
運用イメージ
AMIを変更したEC2を新規作成してそっちで動作確認
問題なければElasticIPを新しいEC2にアタッチ
古いEC2を破棄
これでOSのアップグレードが終わるようになる
ALBは使わない
1台で月17ドルくらいになる見込みだったので、普通に高い
パブリックサブネットにEC2を起動して、EIPを割り当てるつもり
EIP1つは無料で使えるっぽい
S3+CloudFront
Webshの画面は静的ファイルだけなのでS3ホスティングのCloudFront経由にする
こうすればEC2再起動中でも最低限画面は見える
ということで概算見積もりは以下のようになった
オンデマンドインスタンス
12.1ドル/月
年間 145.20 USD ≒ 約18,850円
リザーブドインスタンス1年前払い
4.22ドル/月
年間 106.64 USD ≒ 約14,000円
円安の影響が響いてる
さくらVPS単体だと 900 * 12 で10,800円ほどなので、年間で3200円ほど今より高くなる 1ヶ月単位では266円増える。サブスクリプションが1個増えた程度と考えれば微々たるものか
まぁさくらVPSよりはAWSの方が仕事と直接関係があるので、勉強費用と考えれば3,200円増えても元が取れるかなぁ あと今回の構成にすることで、いくつかメリットがある
Athena+S3構成にすればコンソールからログを検索できる
OSのアップグレード作業を安全に実施できるため、運用負荷が下がる
これが大きい、今は気楽にアップグレードできないので
新規にインスタンス立ち上げて疎通確認し、大丈夫なときだけ切り替えられる
ufwを外してSecurityGroupに寄せられるので、ミドルウェアの保守が若干楽になる AWSの勉強になる