AWSで無限課金しそうになった話
先日とあるプロジェクトでS3にプロフィール画像を登録したイベントでLambda関数を実行して、サムネイルを作成する仕組みを作りました。
仕事後に用事があったので、動作確認をしないまま帰宅したのですが翌朝S3を見ると。。。
hoge.png hoge_thumb.png hoge_thumb_thumb.png hoge_thumb_thumb_thumb.png ...
(ﾟﾛﾟ;)ｴｪｯ!? プログラマなので見た瞬間に何が起きたかは理解しました。
なんとサムネイル画像の保存のイベントから更にサムネイル画像のLambda関数がキックされて、サムネイルの無限生成が発生していました。
幸いS3のキー長の制限かなにかに引っかかったのか１ファイル毎に２００ファイル前後のサムネイルが生成されるという現象で済みました。
_thumb というサフィックスを拡張子の前に付与していたので助かりましたが、これがちょっとした検証のつもりで同じ名前でPUTしていたら無限ループになっていた思います。
久しぶりにヒヤリ・ハットを経験しました。
学び
- イベントを検知するフォルダーとアウトプットの出力フォルダーは分ける
AWS[DynamoDB-Lambda-APIGateway with Cognito]
Cognito認証したユーザーがAPIGatewayを経由して、Lambdaを経由して、DynamoDBにデータ登録する検証をしたのでやったことメモ。
- DynamoDBでテーブル作る
- Lambdaで関数作って、DynamoDBにインサートする。(NodeJS) データはevent.name, event.messageで参照
- Cognito でユーザーIDプール作る
- Cognito認証のサンプルコードをもとにiOSにCognito認証組み込み(今回は匿名認証)
- APIGatewayでリソースとメソッド作る。Lambdaで作った関数にひも付け
- APIGatewayのメソッド設定で認証を有効にして、パラメタをLambdaに紐付ける設定をする
- APIGatewayをデプロイする
- APIGatewayから作成したAPI用のSDKをダウンロードしてiOSに組み込み
- iOSからAPIを実行
- DynamoDBにデータが登録される事を確認する
docker-compose で go get するパッケージを使う
未解決です。
docker-compose で go get しておくようなパッケージ (e.g. github.com/lib/pq)をインポートしているとそのパッケージがダウンロード出来てなくてエラーになる。
アタッチして、go get github.com/lib/pq した後に、go run app.go すれば問題ないが、docker-compose up で一気に起動できる方法を探している。
info.plist の値をBuild Configurationによって出し分ける
いろいろなライブラリでinfo.plistに値を設定して利用しています。 でもdebugとreleaseで値を出し分けたい事がよくあります。
この場合、Build Settings の User Defined に独自の値を設定するとBuild Configuration毎に異なる値を設定できるので便利です。
info.plistから参照するには ${HOGE} のように記述します。
参考
3ヶ月ぶり転職
ちょっと前に5年ぶり転職 - ほげほげというエントリーを書いたばかりですが、オイシックスを8/31に退職しました。 9月からはフリーランスのエンジニアとしてプロジェクトに参画しています。
このエントリーでは将来また転職しようとした時に、会社と自分のミスマッチをしないために今の考えをメモします。 記事のわかりやすさの為に会社名を出していますが、それぞれの会社をディスる意図は全くありません。
簡単に大学卒業から今までの経歴を整理すると以下のようになります。
- 2006/04-2008/03 ハイテクシステム株式会社(SIer)
- 2008/05-2010/05 派遣とフリーランス(Web系)
- 2011/01-2016/05 株式会社ポッケ(モバイルコンテンツ)
- 2016/05-2016/08 オイシックス株式会社(食品系EC)
- 2016/09- フリーランス(アプリ/Web)
ポッケをやめた理由
ポッケでは幅広く開発することができ、今の自分のエンジニアとしての軸ができました。 その上でポッケを転職しようと思った理由は以下の様なものでした。
- お金もっとちょーだい
- もう少し大きなサービスに携わりたいよ(数人で1プロダクトのような)
- 現職以外のマネタイズ方法も経験したいよ
- 開発以外の組織づくりもしたいよ
- 他の現場も経験したいよ(開発フローとか興味あった)
こういった理由で転職しオイシックスに入社することにしました。
オイシックスをやめた理由
何かが出来ない環境になって初めてそれが好きだったことに気づくことがあると思います。 まさに「なんでもないようなことが〜♪」という心境です。
- 開発したい
これが一番大きな理由でした。
僕は開発によって便利や楽しいを増やすことが好きなので、たくさん機能の開発をしたいタイプのエンジニアです。 ただこの会社では開発案件が動くまでに時間がかかり、思うような量の開発ができなそうに感じました。
上場している企業ですし、社員として長く安心して働けそうな感じではありましたが、開発から離れることでエンジニアとして自分の市場価値を下げるのではないかと懸念しました。 自分の売りは開発力と案件の実現力なので、その力を更に伸ばせる開発の現場に戻ることにしてフリーのエンジニアに転職しました。
正社員じゃないのは、転職活動に時間がかかる点と、今回のようなミスマッチの再現を恐れたためです。
根底にある考え
そもそもなんで開発がしたいのか。 開発でサービスを消費者に届けるのが楽しいというのももちろんありますが、理想の働き方を追求したときに開発力がまず必要だと思ったからです。
僕の理想の働き方は以下の様な感じです。
- そこそこ高収入(年収1500万くらい)
- 時間に余裕がある(週30時間労働くらい)
- そこそこ楽しい
- ストレスフリー
こういった働き方をしたいのですが、やはり一般的な会社だと難しいと思っています。 となると自分でサービスを作るか、受託で開発するか、あたりが選択肢になってくるので、現場の力すなわち開発力を維持しておきたいと思っています。 開発については受託も視野に入れると幅広いスキルと、プロダクトを実際に作るまでの実現力を今後も伸ばしていきたいので、開発の仕事をしたいです。
これから
フリーのエンジニアも40代になると案件なくなるという事も耳にしてますし、ちょうど転職も難しくなる年が迫っているのはわかっています。 ただ今回の転職は理想の働き方を目指すためのはじめの一歩でもあり、プロのエンジニアとして長い期間働いていく覚悟を決めたような意味もあります。
先々なにが起こるかはわかりませんが、今はモンモンとした気持ちは無くなり、迷いない日々を過ごせています。
docker-composeで作成したcontainerにattach
Docker Compose について
Docker Composeについて
Composeは複数コンテナのDockerアプリケーションを定義、実行するツール。 Docker fileで設定し、コマンド一つでアプリケーションを開始することができる。
開発、テスト、ステージング環境のようなCIワークフローに有用。
使い方
大きく３ステップ。
Dockerfileでアプリの環境を定義する。これによりどこでも再構築できる。docker-compose.ymlにサービスを定義する。１つの独立した環境に必要なコンテナが同時に実行することができる。docker-compose upコマンドを実行する。環境が構築され使用できる。
docker-compose.yml例
# バージョン
version: '2'
# サービスの定義(コンテナ)
services:
# webという名前のコンテナ
web:
build: . # カレントディレクトリの Dockerfile から生成
ports:
- "5000:5000" # 5000ポートを5000ポートにフォワード
volumes:
- .:/code # カレントディレクトリをコンテナの/codeにマウント
- logvolume01:/var/log
links:
- redis # redisコンテナにリンク
# redisという名前のコンテナ
redis:
image: redis # redisイメージから生成
volumes:
logvolume01: {}
services には 必要なコンテナ が定義される。
