Q&A
T3 Unlimitedは入れていますか？
EC2インスタンスに関してなのですが、npm run buildコマンドをターミナルで打ち込みjavascriptコードをビルドすると高頻度でサーバーへの接続がタイムアウトになり接続できなくなってしまいます。
インスタンスを停止し再度起動することで元には戻るのですが、こちら、何故毎回サーバーが落ちてしまうのかの原因が分からない状況です。
インスタンスの情報は下記になります
OS: Ubuntu 20.04
容量: 30GB
インスタンスタイプ: t3.small
どなたか、原因究明の為、ご助言頂けましたら幸いです
> T3 Unlimitedは入れていますか？
いえ、こちらのツールは入っていないと思われます
ツールではなく設定ですね。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html
T3系のインスタンスだとUnlimitedはデフォルトなので、何も知らないということはおそらく設定は入っていると思います。
回答1件
0
ベストアンサー
こちらに同じようなことを書きましたが
まず調査をしてください。調査をしなければ原因はわかりません。
npm run buildをしたときにインスタンスの各種リソースの使用率はどうなっているかを確認してください。
おそらくはメモリ不足でしょうけれど。
また、ログが出ているならそちらも確認してください。
また、個人的にはそもそもそのnpm run buildはアプリケーションを動かすEC2インスタンスでやる必要がないように思える（ビルドのためだけにインスタンスの性能を上げるのはあまり筋がいいとは思わない）ので、後々はビルドを別のところでやって成果物だけをデプロイするような仕組みにできるとよいと思います。
投稿2021/09/12 15:21
編集2021/09/12 15:21総合スコア7588
ご回答ありがとうございます。
重ね重ね恐縮ですが、何点かお聞きしたいことがあります。
>npm run buildをしたときにインスタンスの各種リソースの使用率はどうなっているかを確認してください。
こちら、試しにインスタンス内で「top」コマンドにてメモリ量を確認してみました所、以下のように表示されました(サーバー全体の使用率部分)
「 MiB Mem : 1945.0 total, 653.8 free, 646.6 used, 644.6 buff/cache 」
こちらですが、「t3.small」のメモリが「2」GBであることを考えますと、かなりギリギリの状態になっているということでしょうか...?
ですが、いまいち分からないのは、インスタンスを再起動し、「npm run build」を行うと、今度はタイムアウトにならずにビルドが成功するのですよね...
ここら辺はいまいち分からない部分ではあります...
>ビルドを別のところでやって成果物だけをデプロイするような仕組みにできるとよいと思います。
今までデプロイするアプリは、インスタンス内でビルドしそのフォルダを公開するような形にしていたのですが、GitHubのようなリモートリポジトリにビルドしたフォルダを含めた方が良いということでしょうか?
> 「t3.small」のメモリが「2」GBであることを考えますと、かなりギリギリの状態になっているということでしょうか...?
キャッシュで使ってるメモリがだいぶあるので単純な数字は当てになりませんが、普段からそれしか余ってないのは心許ないですね。
> ここら辺はいまいち分からない部分ではあります
なので、その理由をはっきりさせるために調査するのです。
npm run buildを行ったら各種リソースの使用率はどうなるでしょうか。
都度サーバに入って調査するのは大変なのでCloudWatch AgentをインストールしてCloudWatch上で確認できるようにする手法を貼った先ではおすすめしています。
> GitHubのようなリモートリポジトリにビルドしたフォルダを含めた方が良いということでしょうか?
ビルドしたものをgit管理するのではなく、どこか別の環境でビルドしておいて、ビルドしてできたものだけを配置して動かせれば、ビルドのためだけにリッチなサーバを使う必要はないですよね、ということですね。
重い処理だけ別の環境で行うというのは定石の一つです。
オンプレの環境だと別サーバを用意するのはかなりコストがかかりますが、クラウドでは従量課金なのでその環境を使った分しかかかりません。
スポットインスタンスで一時的に高性能なインスタンスを使うでもいいでしょうし、AWSを使っているならCodeBuild+CodeDeploy（またはCodePipeline）なんかを使ってもいいでしょう。今ならGitHub Actionsを使うのもいいでしょう。
ただ、これらは今後に向けての話で、今やるべきことが調査であることには変わりありません。
ご丁寧にありがとうございます。
> 都度サーバに入って調査するのは大変なのでCloudWatch AgentをインストールしてCloudWatch上で確認できるようにする手法を貼った先ではおすすめしています
こちら、CloudWatch Agentの料金体系がいまいち分かっていないのですが、無料で行えるものなのでしょうか...?
自分は可能な限り無料で対策したいと考えております。
>ビルドしたものをgit管理するのではなく、どこか別の環境でビルドしておいて、ビルドしてできたものだけを配置して動かせれば、ビルドのためだけにリッチなサーバを使う必要はないですよね、ということですね。
重い処理だけ別の環境で行うというのは定石の一つです。
こちら、別の環境とはどこのことを指しますでしょうか...?
お手数ですが、いまいちイメージが掴めていない為、ご説明お願いできましたら幸いです。
CloudWatch Agent自体は無料です。
ただ、CloudWatch AgentによってCloudWatchに送られるメトリクスはカスタムメトリクスになるので、カスタムメトリクスの料金がかかることになりますが、１インスタンスだけであれば無料枠に収まる可能性が高いでしょう。
あと、個人的な意見ですが完全無料であれこれやろうとすると結局その分工数がかかってしまうことが多いので、料金を確かめた上で必要なところにはきちんとお金を払うべきだと思っています。
ケチるならそれ相応の知識をつけた上で必要性を天秤にかけた上でやってください。
既に「必要なリソースの状態を調べるにはどうすればいいか」ということを調べてその読み方を調べる、というコストが自分に発生していますよね。
もちろんそれはそれでやり方としては必要な知識なので知っておいて損はないですけれど。
どうしてもコマンドでやりたいならこのへんを参考にしてみてください。
細かい使い方については調べれば出てくるので解説はしません。
https://qiita.com/rsooo/items/42f0902d42bab6ecf175
> 別の環境とはどこのこと
どこでもいいので、アプリケーションを動かしている環境以外の場所です。
これだけならそんなに難しいことを言ってるわけではなく、どっか別のところでビルドしてできたものだけサーバに置けばいい、と言っているだけです。
より詳しく知りたいならCI/CDあたりでググってみてください。
ありがとうございます。
一度、CloudWatch Agentについて、調べてみて導入を検討してみたいと思います。
導入するかどうかは本筋とはあまり関係なく、ちゃんと起こってる事象に対して調査をしてください、というのがこの回答で言いたいことなので、どういう方法にせよまずは調べて原因と対処を考えてみてください。
分かりました！
そもそもCloudWatch Agentについて知らない部分が多いので、まずはこのサービスについて調べてみたいと思います
あなたの回答
tips
プレビュー
