JAWS-UGコンテナ支部入門編 #4 で登壇しました #jawsug_ct

3/30(木) JAWS-UGコンテナ支部入門編 #4 で発表の場をいただきましたので、今回はそのご報告です。

ソフト道場の「SIerが目利きする。今日から使えるAWSレシピ」第6回
- 2017年04月20日公開

はじめに

ソフト道場AWSチームの須藤です。

さて、もう3週間経ってしまいましたが、3/30(木) JAWS-UGコンテナ支部入門編 #4 で発表の場をいただきましたので、今回はそのご報告です。120名の方にご来場いただけたようで、たいへん盛況でした。

これからECSを採用しよう、と考える方に向けて、アプリケーション側で意識しておいていただきたいこと、インフラ構築時に意識しておいていただきたいこと、それぞれをベストプラクティスとしてまとめた資料です。

少しでもECSを採用する際のハードルが下がったら、あるいは少しでもECSを採用したあとに困る人が減ったら、という思いを込めて作りましたので、参考になりましたら幸いです。

なお、 今後AWSの新機能や新サービスのリリースによってベストプラクティスが変わることもある ので、その点ご容赦ください。

発表資料「これからECSをはじめる人のための ECSベストプラクティス」

JAWS-UG ECS Best Practices #jawsug_ct from Yu Sudo

※2017年3月以前に作成された資料です。NTTソフトウェア株式会社は、2017年4月1日よりNTTテクノクロス株式会社に社名を変更しました。

発表後の質疑応答

いただいたご質問とそれに対する回答の要約です。

DBのデータソースの解決にDNS(Route53 Private Hosted Zone)を使う、と資料にあったが、DNSの名前解決の負荷が大きくなるのではないか？DNSキャッシュを使うなどしている？

(JAWS-UGコンテナ支部スタッフより)

数十インスタンスのオーダーのシステムで、fluentdによるログ集約のためにRoute53 Private Hosted Zoneを利用してログの転送先を解決しているが、名前解決の負荷が問題になるような挙動には遭遇したことはない。

(須藤より)

今回のシステムの場合、DB接続にはコネクションプールが利用されており、トランザクションのたびに名前解決をする、という動きにはならないため、名前解決の回数がすごく多くなるというのも想定しにくい。あくまで、コンテナイメージの中にデータソースをハードコートしなくて済むように、というやり方のひとつとして採用している。

他の参加者にとっても、知見や気付きの得られたであろう鋭い質問でした。ありがとうございました。