Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 失敗から学ぶAWSの監視
Similar to 失敗から学ぶAWSの監視 (20)
More from 株式会社オプト 仙台ラボラトリ
Recently uploaded
Recently uploaded (9)
失敗から学ぶAWSの監視
- 2. 自己紹介 • abema • 所属/担当 • 株式会社オプト 仙台テクノロジー開発部 • インフラエンジニア • プライベート • ネットゲーム(FF14)
- 3. 今日話すこと
- 5. AWSの一部
- 6. AWSのサービス Amazon EC2 Amazon Elastic Container Service AWS Lambda AWS Batch AWS Elastic Beanstalk Amazon RDS Amazon Redshift Amazon VPC AWS CloudTrail Amazon Elasticsearch Service Amazon Aurora Amazon Simple Notification Service Amazon Simple Queue Service AWS Glue Amazon Athena
- 8. なので以下３つだけ AWS Lambda AWS BatchAWS Elastic Beanstalk
- 9. 3秒で解説する
- 10. 1秒でわかるAWS Lambda • インフラの整備が不要 • 値を受け取って関数だけ実行する • node.js, python, Goなどをサポート • 実態はAWSの余剰リソースの活用
- 11. 1秒でわかるElastic Beanstalk • コードをデプロイするだけでWebアプリケー ションを構築できる • インフラなど必要なサービス群をパッケージ ングしたもの • 構築時は意識しなくてよいがサーバレスで はない
- 12. 1秒でわかるAWS Batch • コンテナ化したバッチジョブのインフラ環境 を、バッチのリクエスト契機で動的に用意し てくれるサービス • ジョブスケジュール機能はない
- 13. ついでに
- 14. 1秒でわかるCloudWatch • 監視するやつ。以下4つの機能がある • CloudWatch Metrics • メトリクスを収集 • CloudWatch Alarm • メトリクスの閾値で通知 • CloudWatch Logs • ログ貯める • CloudWatch Event • イベントに引っ掛けて 何かトリガする • Cron
- 15. 一般的なAWSの監視
- 16. • やり方はいろいろあると思いますが、今回は基本的に • CloudWatchメトリクスにメトリクスをためる • しきい値を超えた時にアラームを出す • という監視のやり方をベースにお話します
- 19. 参考
- 20. • デフォルトで取得可能なメトリクス • CPU使用率/トラフィック • etc ... • デフォルトで取得できないメトリクス • 使用メモリ • 使用ストレージ
- 21. 失敗
- 23. どうしたか
- 24. • メモリ監視のためのebextentions（Beanstalkのインフラ 設定をコード化する機能）の設定を追加 • 設定例がAWS公式で公開されている https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/customize-containers- cw.html • （いや、そんなことするならデフォルトで取得するよ うにしてくれないかな…）
- 25. いま
- 26. AWS Batch
- 28. 失敗
- 30. なぜ
- 31. • 実行中・待ちなどのジョブの状態はAWS Batchのコンソ ール画面（またはAPI）でしか取得できない • CloudWatch メトリクスには収集されていないため • 失敗ジョブが発生したら通知 • 待ち状態のジョブが一定数溜まったら通知 • などができない • （というかロクに監視機能がない）
- 32. どうしたか
- 33. • AWS batchそのものにCloudwatchと統合された機能がな いので… • あきらめて定期的にAWS Batchの状態をAPIで取得して、 CloudWatchメトリクスに送るLambdaを書いている
- 34. Lambda
- 37. 参考 呼び出し 実行時間 エラー率 スロットリング (AWS用語: API呼び出し数の上限) kinesisの呼び出しなどに使う （よくわかってない） DeadLetterを 呼び出しできなかった数
- 38. • デフォルトで取得可能なメトリクス • 失敗ジョブ数 • 実行時間 • デフォルトで取得できないメトリクス • 使用メモリ
- 39. 使用メモリ
- 40. なんで収集しないの？
- 41. • Lambdaは実行時間✕関数に設定したメモリで課金される • 関数の使用メモリのメトリクスは取得してくれない • 実際の使用メモリに対して大きすぎるメモリを設定し てしまうなどして無駄なコストが掛かる • (微々たるものといえばそうですが)
- 42. 【参考】Lambdaの料金 memory (MB) 無料利用枠 (秒) 100 ミリ秒ごとの価格(USD) 128 3,200,000 0.000000208 192 2,133,333 0.000000313 256 1,600,000 0.000000417 320 1,280,000 0.000000521 384 1,066,667 0.000000625 448 914,286 0.000000729 512 800,000 0.000000834 ピンと来ないと思うので… 128MBのLambdaが丸一日ずっと実行状態になるようなバッチで（無いと思うが） 0.000000208 * 10 * 60 * 60 * 24 = 0.18USD(約20円) 512MBだとその4倍で 0.72USD(80円)
- 43. • Lambda実行後のCloudWatch Logsのログストリーム末尾に以下 が表示される • Lambdaで定期的にCloudWatch LogsをAPIで取得し、上のよう な文字列で引っ掛けてメモリ使用率を取得、メトリクスに投げる • ただし、メモリに余裕があるからと行って無邪気に使用メモ リを下げると痛い目にあうかも… • Lambdaはメモリの割り当て量に対してCPU能力が決まるの で… REPORT RequestId: 9f74603f-229e-4f6d-a307-7a0fcbd2d62b Duration: 268.89 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 68 MB え、CPUも監視したい？ それはどうやって実装するのか私にはさっぱり… CPUのパワー不足により実行時間が相対的に伸びると思うので、そこで監視でしょうか
- 44. 最近後悔していること
- 45. 監視設定系の管理
- 46. • 通知用Lambda • SNS(simple notification service)に飛んできたCloudWatchア ラームをSlackに投げたりするのにLambdaを使っている • Slackになげるやつは文字列整形のために通知内容ごとに個 々に関数を書いているのですが、数が増えてきてしっちゃ かめっちゃかになりつつある • 監視対象AWSのサービスはもとより、CloudWatch Alarmから来るかCloudWatchEventで来るかなどで 通知のjsonスキーマが違うので、細かくやってしまった
- 47. • CloudWatchイベント • Lambdaを定期実行したり、条件で引っ掛けて起動するのに使 っているのだが、これも数が増えてきてしっちゃかめっちゃか になっている • ServerlessFrameworkなどでLambdaに関連付けられる形でコ ード化されているのがほとんどなんですが、AWSコンソール 上でパッと見たときにはカオス感がある • コンソール上ではどのイベントが何に紐付いてるかわかりに くい • タグ付けもできないので、どう管理するとすっきりするのか… *タグ：AWSには各リソースに"タグ"をつけることで リソースをグルーピングして表示したりする機能があります
- 48. • CloudWatchアラーム • CloudWatchイベントと同じ状態 • ただこちらはメトリクスに対して手でいろいろ設定して いるので、コード化もされていない • SNSに投げるところまでは手で設定してしまっている • やはりしっちゃかめっちゃか *SNS：Simple Notification Service AWSの通知サービス。メール通知やlambdaの呼び出し
- 49. まとめ • LambdaやElasticBeanstalkではマネージドな監視基盤が提 供されているが、メモリ監視だけは自前でどうにかしな いといけない • Batchは監視する機能が何も用意されていない • CloudWatchアラーム・イベントなどの設定をどう管理し よう
- 50. ご清聴ありがとうござ いました