はじめに
AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催
こんにちわ。Wano株式会社エンジニアのnariです。
awssummitなう#awssummit
— nari@エンタメ系エンジニア (@fukubaka0825) June 13, 2019
この度、AWS Summit Tokyo初参戦してまいりましたのでそのレポになります。（2日目のみ)
幕張は遠かった。。。けど非常に充実した1日でした！
AWS Summit Tokyo参加レポ一覧
AWS Summit Tokyo 2019 2日目 参加レポート その1 "コンテナとサーバレス " - Qiita 👈今ここ
AWS Summit Tokyo 2019 2日目 参加レポート その2 "動画メディアクラウド利用事例" - Qiita
AWS Summit Tokyo 2019 2日目 参加レポート その3 "認定者ラウンジ偵察とクラウドにおけるアーキテクチャの設計原則" - Qiita
今回のAWS Summit Tokyo参加の目的
- チームのメインプロダクトが動画メディアを扱うので、動画関連メディアでのクラウド利用事例を視聴する必要があった(ストリーム配信がなかったため現地に行く必要があった)
- せっかくAWS Certified Solutions Architect (Associate) を最近撮ったので、資格を持ってないと入れないと噂の認定者ラウンジを偵察する
参考:３週間でAWS認定ソリューションアーキテクト-アソシエイト-とったので、勉強法などまとめてみる - Qiita
コンテナ化されたアプリケーションのAWSでの構築・運用指針 10:00-10:40 会場：D
- CICDへの要求の高まり
- CICD devopsのプラクティスをコンテナを使うと楽にできることに皆気がつく
-> クラウドサービス提供側もしかり、 awsも様々提供- コンテナインスタンス数の伸び 300% 過去15ヶ月
- CICDにプラスして、アプリケーションへのフォーカスを実現への要求
- VMの世界だと、企業がインフラ管理をする必要がある
- 多くのチームがインフラ管理に時間が終われ、ユーザーに価値を届けられてな
- そこでクラウドの時代が到来
- コンビュート消費モデルの変化
- EC2だと、背後のインスタンスやサーバーに依存 そこに配慮する必要ある
- そこでfargateが必要になった
- Fargateとは
- 使ったcpuの分だけ払う サーバレス サーバーのことを考えなくていい
- パッチを当てるのはfargate
- サービスを実行するだけ コンテナ上で
- この一年で1000万の新しいタスクを毎週実行
- 値段を半年で下げてより採用率が上がった
- CDK
- これからはymlではなくアプリの言語で管理 IaCが促進していく pulumiと同じような思想
- これからのsdkの進化を我々が一番楽しみとしている
- ecsはsdkやawsのベースを支える一部として機能
- pulumiと同じような思想
- ECS EKS
- ecsはeksと違って全てのプロビジョニングをカバーしているわけではない
- eks上流レベルで必ず互換性
- App Mesh
- コンテナやサービスが乱雑に配置 関係性を管理できない
- envoy だけではなくどんどん様々なサービス対応していく
- みんなが本当に欲しいのは適切に管理されたネットワーク
- app側がまえに出て、インフラ側はどんどん後ろになっていく
- 細かいコントロールを取れる
- 結合組織 全てのやりとりを可視化
- コンテナを使った事例 マクドナルド
- ecsベース マイクロサービス ベストプラクティスを使用
- 高レイテンシー 2万以上の毎秒トランザクション砂漠
感想
- SDKの進化は待ち遠しいですね、、ymlではなくappと同じ言語でインフラも管理できる世界まであともう少しなのかもしれないですね
- app Mesh然りservice meshのプロダクト周りは触ったことがないので、どこかで触ってみたい
- マックのシステムはecsベースなのはびっくり。どんどん世の中の基盤がコンテナ化していっていますね。
サーバレスのエンタープライズへの拡大とベストプラクティス 11:00-11:40 会場：D
サーバレス とは
- 自動的にスケール
- インフラのプロビジョニングや管理がふよう
- 価値に対して支払い
- 高可用性 セキュア
サーバレス によって
- アジリティの向上
- 運用工数が減る
サーバレス アプリケーション
- イベントソース
- ファンクション
- サービス
AWS lambda
- 言語や環境に依存しない
- 様々なユースケース
- iot マイクロサービス webアプリ バッジ チャットbot itオートメーション
よくある懸念点
- 開発体制 ガバナンス セキュリティ パフォーマンス ロギング
この講義で全て説明したいく
devops
- マストである
- app インフラもコードで管理
- CI/CD テストの自動化
SAM
- サーバレス アプリケーションモデルの略
- クラウドフォーメーションの上に
- templateが協力 cloudformationだと百行くらい
- cloudformationと同じような機能 ＋ 組み込み関数
- CLI ローカルでデバック デプロイ テスト可能
- step function local、dynamoDB local 、localstack ローカルでサーバレスapp作成できる
- テストやデプロイフローに関しては、今のCI/CDにSAMを組み込むだけで問題ない
セキュリティ
- ファンクションポリシー
- 豊富なtemplate
- 実行ロール
で制御している
ガバナンス
- このファンクションプロパティはタグつけされているか
- 組織ポリシーに実行ロールはあってるか
- ファンクションがどうVPCにあるのが正しいのか
- 以下のサービスで実現
- aws cloudtrail
- 誰が変更したのか
- データイベント管理 呼び出しのリクエスト全てトラッキング
- aws config
- 継続的な記録
- awsリソースに対する構成変更を追跡
- 自動的な修復機能を組み込める
- aws cloudtrail
コードに対するガバナンス
- コードチェックをデリバリパイプラインで強制実行
- ライセンス要件に準拠しているか
- ３rdパーティの更新や競合チェック
- lambda レイヤー
lambdaレイヤー
- インミュータブル 不変である 変更不可 ユニークである
- 不要なものは排除できる
- configで変更管理してできる
AWS SAM globals
- レイヤーをコントロール、誰が、どのバージョンを作成したのか、変更したか管理できる
モニタリング ロギング
- cloud watch
- プラットフォームにまたがったサービス
- cloud watchメトリクス
- 起動回数、同時実行秒数、エラーetc
- cloudwatchlogs
- どういったものをログするのか指定できる
- lamdaなら基本的なリクエスト情報を内包
- ここからログからのメトリクスも取れるよ
- カスタムダッシュボードを作れるよ
パフォーマンス改善
- AWS X-RAY
- profileとトラブルシューティング
- 基本的なフローをビジュアル化するのに優れている
- 色でエラー可能性を可視化
- functionのデバッグの秒数、エラーを取れる
- アナリティクス performanceの異常など図式化
ファンクションのためのリソース
- メモリをふんだんに使うと、パフォーマンスは良くなる
- 10秒の実行時間の差が生まれたりする
- コストはあまり変わらないからメモリをあげよう
- x-rayで調整していただきたい
何が悪いかを調査
- xrayをon
- lambdaのロギングを侮らない
- もっとも意味のあるメトリクスは業務ロジックと密接
サーバレス に向けて
- ツールを使おう
- CI/CD
- ガバナンス
- レイヤーを使うと依存関係整理ができる
- モニタリングにcloudwatch
- performance改善にx-ray