AWSでのやらかした話

Transcript

1. AWSでのヒヤッとやらかした話
2. 自己紹介 • 1969年生まれ • 勤務先：クロスケアフィールド株式会社 ◦ 自社サービス開発、メンテナンス • スキル：Ruby, Vue, Nuxt ◦ 元グラフィックデザイナー ◦ プログラマは３０歳から • 趣味：料理、機械修理、ゲームなどなど
3. クロスケアフィールドのサービス 患者中心の医療系SNS 2014年 ファーストリリース ビデオ通話アプリ 2024年 ベータリリース オンライン診療 予約システム 2025年 アルファリリース
4. AWS利用は2023年から 直前の環境はMicrosoft AzureのVMで構成 デプロイは手動でAPIサーバーのファイルを上書きして再起動。 Vue.jsは手元でビルドしたファイルを Nginxの公開ディレクトリに上書き Azure VM Ngix Puma (Rails APサー バー) APIモード リバースプロキシ Vue.jsアプリ ケーション Azure Database for MySQL
5. AWSで構成するにあたり、 ECSを利用したい！ コンテナサービスを利用することで、 VMのOSその他の足回りメンテナンスから解放されたい 開発もDocker-Composeを利用することで、環境をほとんど本番と同じように構成できる RailsコンテナはProduction構成のDockerFileでビルドすれば、ECRにPushしてデプロイできる
6. Railsの方はバッチリだ！で、 Vue.jsは？ 開発環境上ではVue.jsは別コンテナ　→　テスト中はDevServeを起動してうまいことできてる Nginxコンテナを作る？　→　コンテナ作っても結局ビルドしたファイルを配置するだけだし。 コンテナ増やす分コストも掛かりそう ビルドした Vue.jsのSPAファイルを S3で配布 すればいいんじゃね？
7. ビルドした Vue.jsのSPAアプリをS3で配布する CloudFrontの設定でnarrativebook.jp/のパスで来たものをS3バケットnarrativebook-staticバケットに回送 (APIサーバーへのアクセスのために narrativebook.jp/api*はRailsコンテナへ回送 そのままだと、SPAのパス(例:narrativebook.jp/maintimeline/1)のファイルを取りに行ってしまうので、 SPAの ルーティングに乗らない 　　　　　　　　　　　　　　　　　　　　　 ↓ バケットへのアクセスはCloudFront以外許さず、index.html以外のアクセスは許さない =余計なパスにアクセス したときには404もしくは403エラーが発生 　　　　　　　　　　　　　　　　　　　　　 ↓ 404及び403エラーを返した場合、エラーを握りつぶして index.htmlへ回送=SPAのルーティングで処理される
8. Vue.jsのデプロイ ローカルでビルドしたファイルを S3に上書きアップロード S3に上書きアップロード 上書きアップロード
9. そして事件は起こる
10. 操作していると突然トップページに遷移してしまう 実は閲覧したいページの閲覧権限がなかった →　本来なら403エラーページが表示されるはず・・・ バックエンドのAPIが403エラーもしくは404エラーを返したときも同じことが起きていた 対策:　結局、バックエンドでは 403も404も全て400で返すことで対応 404及び403エラーを返した場合、 エラーを握りつぶしてindex.htmlへ回送=SPAのルーティングで処理される
11. フロントエンドとバックエンドが繋がっていない 環境を揃えたStagingとProductionがあるが、 Production環境ににStaging用にビルドしていたファイルをアップロードしていた 画面の一部にビルドバージョンと指向先環境識別の文字列をこっそり表示していたので判明 デプロイは常に深夜(0時ころ)に行い、デプロイ後毎度動作確認していたのですぐに気づいた 対策:　気をつけよう
12. 抜本的な対策 現在のVue.js配布方法が問題。 VueからNuxtに変更してNitroサーバーコンテナとRailsコンテナを並列で動作させる 最新のプロダクト「NarrativeReception」では導入済み 残りもこれに移行する予定・・・
13. 結論 結局ヒューマンエラーが一番問題 できるだけ間違いが発生しないように環境を設計すること こそが大事 AWSあんまり関係なかった