これは Livesense Advent Calendar 2023 DAY 9 の記事です。
はじめに
インフラGの鈴木です。好きな競輪選手である松井宏佑選手がG1で2着になったのが本当に悔しかったです。今後も応援を継続していきたいと思います。
ところで、今年は色々ハマったので、お焚き上げがてらブログにすることにしました。
今年やった案件
- オンプレのバッチサーバーをECSに移行
- オンプレのキャッシュサーバをElasticacheに移行
- オンプレの認証サーバをECSに移行
- EC2で動いていたアプリケーションをECSに移行
リブセンス入社前まではEC2おじさんでした。入社後はナウいコンテナを触りまくったので、そこはかとなく成長を感じます。昔はタスクロールとタスク実行ロールの違いもわからなかったのに、今ではECSの権限周りは少しずつわかるようになってきました。
今年ハマった箇所と解決方法
セキュリティグループに穴空いてなかったけどバッチが正常終了したからテストOKにした
見出し以上に言うことがないんですが、懺悔させてください。非常に古いバッチをオンプレからECS run taskに移行する案件でした。
バッチを走らせた後にmemcachedにデータが格納されていれば正常な動作でした。バッチが正常終了したのを見て、データが入っていると思い込んでテストをOKとしました。
実際はバッチからmemcachedへのSGに穴が空いておらず、当たり前ですが、データが入っていなかったのです。テストNGですね。
なぜ気が付かなかったかというと、バッチのコードがレガシー&適当すぎてmemcahedとの通信エラーが握りつぶされており、正常に動いているように見えたからです。
余談ですが、移行対象のバッチにはスクリプトの末尾にexit 0と記載されていて、異常終了しても正常終了する(!?)男気溢れるバッチもありました。
ここから学んだこと
データのIN/OUTをちゃんと観測するという当たり前を学びました。またtryから続く文字列には気をつけようと思いました。
またこのような古代バッチはリファクタリングによって消滅しました。完。
secure属性あるcookieをhttpで通信しようとした
これも見出し以上に言うことがないんですが、secure属性つけているのにhttpで送っていたので、cookieが送られずに消えました。
検証だしhttpsにするのめんどいなあ…とhttpにしたことによって、ハマってよりめんどくさくなりました。
AWSのALBはhttpsで通信するのが簡単だというのに、何故そこを横着したんだろうと今ではよくわかりません。
ここから学んだこと
cookieについて深く学ぶ機会になりました。この辺りはパッと出てくるようになりました。
- secure属性
- https通信のみでcookieを送る
- httponly属性
- javascriptからcookieを読めなくする
- domain属性
- cookieを送るドメインを指定する
- domain属性は癖があるので以下の素晴らしい記事を何回も読みました
またこの時の認証はOAuth2認証でしたので、これについて以下同人誌で学びました。素晴らしい本だと思います。
ドキュメントに必要権限が書いておらずコードを追った結果強い権限をつけることになった
とあるOSSのワークフローエンジンを使っていました。タスク実行用の巨大インスタンスを常設し、そこで処理を行なっていたのですが、ECS化にあたって都度タスクを立ち上げてスケールアウトする方式にしました。
つまり、ECSのタスクロールにECS Taskを立ち上げる権限をつけなければならないです。ドキュメントには
The key needs permissions for ECS and CloudWatch.
としか書いていなかったので、ecs:*とlogs:*をつけて検証しましたが、結局タスクはうまく立ち上がりませんでした。
結果から言うとECSFullAccessをつけたら動きました。原因を調べようとコードを追っていくと、ドキュメントにないIAMの権限を複数使っていることがわかりました。
ここから学んだこと
OSSはドキュメントに書いてある情報だけでなく、コードを追っていくことも大事ということを学びました。
これに関して、ドキュメントを修正するPRを投げることが正しいエンジニアのムーブだと思います。余裕のある時にやろうと思います。
APIにリクエストを送ったら504になったからクライアント側で分割して送った
とあるサービスのAPIを利用していました。サービスを利用する頻度が増えるたびに送信リクエストが増え、ある時期ついに504が返ってきました。
APIサーバーの限界を知ったので、クライアントで対応するようにしました。一度に100程度のリクエストを送っていたのですが、分割して10個ずつ送るようにしたら解決しました。
ここから学んだこと
クライアント側で悩むことで、逆にサーバー側の実装について考えるきっかけになりました。
あるあるだと思うのですが、大きなサイトを運用するようになると、例えば以下のようにインフラのコンポーネントが増え、どこでなんのエラーが返ってくるかわからなくなります。
- CDN
- リバースプロクシ
- ロードバランサー
- アプリケーション
なので、基本に立ち返って、HTTPについて学ぶことにしました。それについては以下の書籍がとても良かったです。
ハマりから学んだこと
記事にして改めて「なんでこんなことに悩んでいたんだ…？？？」というものばかりでした 。
ハマってる時間は本当に辛いです。これを解決するために他人に何で悩んでいるかを聞いてもらうだけでも、要点が整理されて解決への突破口が見えることが結構ありました。
リブセンスでは今やっていることをSlackに書き込むWorking Out Loud(WOL)というコミュニケーションスタイルがあります。
これを実践すると、今やってることを書き込む間に悩みが脳のバックグラウンドで整理されるのか、Slackに書き込んだ数分後に「ア…」と解決の糸口が見えることが結構あります。
技術以外でも何かに悩んだら、まず文字として書き出すといいかもしれません。そこに答えがあるかも…。
