AWS:t2.microとt2.mediumのインスタンスへの負荷経過観察

経緯など

今こういうサービスを開発しており、まあほぼほぼできているけども、検証作業もひつようなので、実質ベータ版という感じである。

不動産法人向け写真共有SNS Snappim
https://www.gaikanmarket.com/

Pythonで開発（Django+AWSLambda等）しており、インフラはAWS。EC2+RDS(Postgre)+S3+(あとroute53とかも使ってるけど省略・・・)とAWSだと一般的なアーキテクチャだと思う。

写真共有SNSなので、最近のスマホで撮影するような画質の画像を同時に10枚とかAWSのS3にアップしてサムネイルとかも透かし入りで作るという機能があり、おそらくその辺が結構メモリを食う仕組みである。（最初はDjangoオンリーで開発してたのだけど、メモリ負荷がどうしてもカバーできなくて、AWSLambdaと分業するプログラムに作り変えた。Lambdaはホント有り難い。理由も割と明確でPythonのモジュールの画像処理のPILというモジュールがメモリ解放でうまく行かない場合が比較的報告が上がっていたので、その辺が原因だと思い、メモリ解放が怪しい関数をLambdaに分散したというわけ。）

検証に使っているt2.microとサーバーの調子

t2.microがお値段的に安いので、検証用につかっているがスペックは下記のような感じらしい
- CPU：1コア
- メモリ：1G

と、いうことで、自分が10年前に仕事で使っていたレッツノートのメモリが2Gだったような気がする。あと今開発に、よく使っているmac miniは8Gだったので、調べてみてなるほどローカルのDjango開発サーバーのほうがインフラスペック上になっていたのか・・・ということを知った。

t2.microだと文字情報メインの個人ブログだとかくらいなら結構さばくのに良いのかも。一方自分のサービスの特性上、ではt2.microだと、メモリオーバーとかの影響だと思うけど、サーバーがイカれて404エラーでないはずの関数に404エラーが出て再読込何度かすると直るということや、謎のパスが表示されてHTMLがパースされないがしばらく（5分以内くらい）すると直るという症状が現れていた。まあ、メモリが小さいパソコンでyou tubeを再生しようとして、止まってしまうような感じの事象だろうと思われる。

と、いうわけでt2.mediumに変えてみた

t2.mediumのスペックは画像処理を10枚するくらいなら大丈夫そうかなというのと値段も予算内だったというので、早速切り替えてみた。AWSはこの場合、ボタン一発で変えられるので、物理サーバーメインの時代と比べホント楽になってきたんだろうなぁという感慨がある（自分はオンプレミスのものはラズパイでCGIサーバー作ってみただけなので大規模なものの経験はない・・・）

t2.medium
- CPU：2コア
- メモリ：4G

今日から、このインスタンスでどれくらいさばけるか検証してみたところ・・・t2.microと比較してページ遷移など動作が機敏になったのは間違いない。しかし、うーんたまにサーバー落ちるな^^; 画像処理は負荷が大きいんだなァ（多分、結局それが原因と思われるので・・・違う原因かもしれんけど・・・）まだまだ上のインスタンスが必要かもしれないなァ・・・

また引続き研究しよう・・・