ec2

Lambda+S3+EC2を使用してできるだけ安くリアルタイムwebPエンコードをやってみる

S3にアップロードされる jpg画像をリアルタイムで webP にエンコードしたかったので 色々やってみた。   要件 S3 バケットには毎月1000万枚の2.2MB程度の jpg画像がアップロードされると仮定 これをアプリが引っ張る前にできるだけで速く webP にエンコードする必要性があります。 webP にエンコードする理由としては、画像の容量が小さくなることでユーザーのストレスを無くす、S3 にかかる料金を安くする、CloudFront の料金を安くするため。 ちなみに何でアプリでやらないかというと、iPhone で撮った生の画像を iPhone でエンコードを行うと、アプリがフリーズするぐらい結構重い処理だからです。致し方なし。   ① Lambda だけで全てやってみる S3 にアップロードをトリガーとして Lambda を起動して、Lambda でエンコードから S3 にアップロード、既存の jpg画像を削除を行うと、最小スペックで 22秒という脅威的な数値を叩き出します。 ちなみにメモリの使用量は 108/107MB 程度です。重いなあ… 全ての Lambda スペックで試し、一番安いスペックは 256MB でした。 これでも 11秒です。 256MB 枚数 秒数 課金 1枚辺り実行時間 無料枠 1秒辺り課金額 10000000 110000000 452.028 11 1600000 0.00000417 20000000 220000000 910.728 ちなみにひと月で 10000万枚を捌き切るにはこの Lambda 関数は並列で 42 個、必要になります。 $452 * 42 = 約210万… センキューAWS! これに CloudFront の料金も加算したらとんでもない額ですね。   ② エンコード用のサーバーを用意してみる not EC2 Lambda 関数を2つ用意し、Lambda – webP request(128MB) は Convert Server にある変換用サーバーにリクエストを送り、Convert Server がステータスコード 200 以外を返したときは、Lambda – webP encoder を呼ぶ係、Lambda – webP encoder は Convert Server  に代わってエンコードしてくれます。 Convert Server は Lambda の料金を節約するために、リクエストを受け取った瞬間に 200 を返すようにしています。サーバーにリクエストがくれば途中で天変地異や、タイミングよくサーバーが壊れる、リソース不足以外で、きちんと動作するようなコードであれば対策はできるであろうと思います。 この構成にしたところ、通常時(Lambda – webP encoderが呼ばれない)であれば、課金対象実行時間が 1,500ms となるので、Lambda だけだと { (1.5 * 10000000)…

Vultr.com $5 VPS と AWS EC2 t2.micro どっちがオススメか

初めて精神安定剤みたいのを買いました。 今後外出するときは使用してみたいと思います。   背景 会社のHPなどサービスを提供する際に停止してもそこまでクリティカルでないものを 如何に安く運用するかと考えたときにVPSかEC2かで悩んだので色んな観点からまとめようと思った次第です。   EC2以外の選択肢 EC2は思ったほど性能が良くない(と耳にしたことがある)ので クリティカルじゃないものなら敢えてEC2じゃなくて他社のVPSで良いのではと思う 国内のVPSだと さくらインターネット GMO カゴヤ ConoHa 国外だと Vultr.com cloudatcost AlphaRacks とか色々あります。 この中でもVultr.comは安くて安定性も良かったので 今回は Vultr.com $5/m のVPSとEC t2.microを比べてみます。 スペックはどちらも 1Core / 1G です。 月額$2.5で東京リージョンがある激安SSD VPSを契約してWordPressを移行した「Vultr」   スペック EC2 t2.micro Vultr  $5 CPU Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz Virtual CPU MEM 1G 1G SSD 8GB (gp2 – EBS) 25GB OS CentOS 7.3.1611 CentOS 7.3.1611 参考 ap-northeast-1a 東京リージョン どちらも CPU/MEM は 1Core/1G です   UnixBench t2.micro – 1回目 [crayon-5b4f820853638769131633/]   t2.micro – 2回目 [crayon-5b4f82085364c382594301/]   Vultr $5 – 1回目 [crayon-5b4f820853654473998171/]   Vultr $5 – 2回目 [crayon-5b4f820853658463353782/]   結果 – UnixBench EC2 t2.micro Vultr $5 1回目 1586.7 1303.6 2回目 871.6 1333.7 1回目は t2.micro が優勢だったけどこれはT2インスタンス特有のバーストです。 クレジット残高が無くなったので2回目は本来の性能(言い方が難しい)になってます UnixBenchって何だかんだCPU寄りの結果だと思ってる(個人的に)ので fioもやってみたいと思います。     fio $ fio -filename=/tmp/test2g -direct=1 -rw=…

作ったAMIからインスタンスを作成するとSSHのパラメーターが変わる

背景 Auto Scaling Group の起動設定の元となるAMIを作成する際に SSHのPasswordAuthentication yesとしてAMIを作成をすると 復元するときにPasswordAuthentication noに戻ってしまう問題   原因 cloud-initが原因 [crayon-5b4f820853b9a980346429/] ssh_pwauth: SSHのパスワード認証の有効/無効   cloud-init について Package provides configuration and customization of cloud instance. 僕の認識があっていれば起動時に毎回実行されるinitスクリプト(例外有り) 参考: cloud-initのデフォルト挙動を徹底的に調べてまとめてみた -結果ソースコードを読んだ-