Foreverly

メモ帳

AWS Summit Tokyo 2018の聴いたセッションのメモ

AWS

聞いたセッションのメモ セッションだけ聞くなら会場ではなくストリーミング配信をみるのが快適ということに気がついてしまった。

オペレーションの最適化

  • ベストプラクティスに基づく準備
  • 適切なモニタリング

  • 適切な運用

  • Well-Architected framework

  • 課題

  • AWS Trusterd Advisor

  • Well-Architected framework クラウドアーキテクチャ設計と運用の考え方とベストプラクティス

  • 運用上の優秀正
  • 実現のための大原則

  • 確認のための質問

  • Operation as codeの実践

  • config,cloudwatc→lambdaで対処するオペレーションの自動化
  • 注釈でドキュメンテーションをする.デプロイしたらplaybookなりが更新される
  • 頻繁に小さく可逆な変更を加える。ワークロード側も変えられる設計にすべき
  • 頻繁に運用手順を見直そう。定期的にGamedayを実施して手順をレビューする。効果があるか、効率化できるポイントを探す。
  • 障害を予想する。机上演習Pre-mortemを実施する。障害シナリオとそのインパクトを理解。対応手順が効果的であることぉ確認、チームがそれらに詳しくなる。
  • イベントと障害対応から学ぶ。うまくいった対応も塩お愛した対応も振り返る。イベントから学んだことをチームで共有する。ログを集めて、可視化しておこう。athenaとか 確認のための質問 運用がビジネスにどんな影響をあたえるのか、運用が客観的に回るっているのか。
  • 運用における優先度を決める要因はなにか

  • どのようにアプリケーション

  • 実際のお客様環境によくある課題

    • タグを管理・活用しているか
    • デプロイ時に強制 tagつけ忘れないようにCloudformationその他のデプロイツールやiAMポリシーで縛る。AWS Service Catalogを利用
    • AWS Configで必須タグが付いているかをチェック。事前定義済ルールのrequired-tagsを利用。対象となるリソースタイプやタグを編集。
    • タグをキーにAWS Sytem Managerを使ってタグを使った管理もできる。リソースグループ化して管理。グループ化したリソースに対して一括処理も可能。
    • タグで頑張りすぎないことも大事。
    • タグの設定指針 awS Tagging Strategyをもよう。
  • メンテナンスの通知は受け取れているのか
    • メールを見逃す。特定の担当者にしか行かない。社内のチャット
    • aWS Personal Health Dashboard
    • リソースに対するメンテやissueが表示されるダッシュボード
    • CloudWatch Eventsと連携してイベントに対するアクションを実行
  • awS HEalth API & AWS Heallth Github repository
    • aws-health-tools　を使えばチャットツールやｓNS通知に自動化できる
    • 大体の連絡先の活用
      • 合うぃ急の連絡先、操作の連絡先、セキュリティの連絡先
  • 複数のアカウントをまとめて管理する
    • 部門ごとやアプリケーションごとにアカウントを作っているけど、ガバナンスを聞かせられない。
    • 請求統合をおこなっているけど、各アカウンとの利用状況が把握できない
    • 請求統合されたアカウント感でRIを管理はいや
    • AWS Oraganizationによえう請求統合がソリューション
    • Masterアカウントにまとめて一括請求、ボリュームディスカウントもこれに適用
  • AWS Organization
  • 一括請求のみを有効化
  • 複数のAWSアカウントに適用するポリシーを集中管理できる
  • AWSのサービスへのアクセス制御
  • AWSアカウントんお作成と管理の自動化
  • AWS Config連携、AWSFirewall Manager連携、SingleSignOn連携
  • Cost Explorer API
  • Cost Explorer API, CustomReport
  • csvだけでなく、jsonでも取れる
  • aws-cost-explorer-report
  • api使うとお金がかかる
  • Reservide Instanceの共有拒否設定
    • 本当は複数のアカウントでサイズ関係なくうまくばらすこともできるので、共有してほしい。
    • それでも共有したくないなら、RI割引共有の設定で共有したくないなら設定できる
  • AWSサポートは活用できているか
    • 複数のアカウント感でナレッジが共有されず、何度もの同じことを聞く
    • 社内で使っている課題管理システムと連携したい
    • サポートの調査が思うように進まない

  • AWSサポートAPI

    • サポート問い合わせの自動化や問題管理ツールとの連携
    • サポート問い合わせのエクスポート
    • Trusted Advisortとの自動連系
    • case_life_cycle.html, trustedadvisor.html
    • ビジネス以上でないと古ファンクションは使えない

  • サポート問い合わせのベストプラクティス

    • 一つのお問い合わせで関連性のない複数の質問をしない
    • 問い合わせ対象リソースの所有者が起票していることを確認する
    • 適切な緊急度を設定
    • 問いあわせ時には以下の内容を添付
事象の発生時間(タイムゾーン)
事象が発生したリソースの詳細(リージョン・リソースID・名前)
発生した事象の詳細：
SdKやCLIのエラ＝であればそのエラー出力
可能であればAWSのCLIのの場合は--debug
  • AWS Trusted Advisor
    • リアルタイムガイダンスを提供してくれる
    • AWS Trusted AdvisorとCloudWatchの連携
    • AWS　Limit　Monitor　

Well-Architectを使って準備し、Trusted Advisorを使って環境を見直しておこう

Fargate

コンテナのメリット - パッケージング - 配布 - イミュータブルインフラストラクチャ

アプリケーション開発に集中

1台のサーバでDockerコンテナを使うのは簡単だが、サーバが増えると大変

  • ECS
    • コンテナはタスクという単位でタスクの配置やスケールのマネージド 動作イメージ ECS EC2インスタンスとタスクがある。これを提供してくれる ECSアーキテクチャの整理 Taskアプリケーションを構成する1つ以上のコンテナ(群)実行単位 Container Instance Taskが起動するEC2インスタンス Service　ロングランニングアプリ用スケジューラTaskの数 Cluster

Fatgateはインスタンス管理不要 　Fargateの上にTaskが起動。EC2インスタンスを増やすことなく仮想サーバー側の管理が不要 Taskだけがスケールされる

Codecommit codebuld ECR Fargate ECK

コンテナ管理にひつようなもの サービスディスカバリ Route53,ALB ロギング、モニタにリング　CloudWatch セキュリティ　IAM　VPC　パラメータストア スケジューリング タスクプレースメント

サービスディスカバリ サービス同士が疎結合になるように構成するのがベストプラクティス、生存時間が短いので各サービスが自身が接続する先を見つける必要がある ECSではALBと連携 ALBをエンドポイントとしてつかう ECAサービスディスカバリの利用 名前解決で、ALBを使わずRoute53のDNA名で自動的に登録することができる

ロギングとモニタにリング コンテナのアプリは外でSTDOUTに出力する コンテナインスタンスとかリソースよりサービスを管理するのがよい

CloudWatch awslogsでCloudWatｈLogsに送信される 1つのTask内に2種類のコンテナを定義する アプリケーションコンテナ ロギング用のコンテナ 一次共有ボリュームにログを出力しロギングコンテナがcloudwatch logsに転送 ロギング処理を別コンテナにまかせる サイドカー構成

Fargateはコンテナにインスタンスの管理は不要でタスクのみ。

Fargateより、より細やかなECSクラスタ管理をつげんできる ECSクラスタの状態変化をリアルタイムに検出する 監視システムにEventログを保存してくらすたの　状態を可視化する 特定のタスクが落ちたときに気づける状態変化に気づける

EventStreamによるリアルタイムなイベント検知 ECSクラスタの状態変化を通知する Evento通知の到達性は少なくとも１回

セキュリティ アクセス権限の考え方 IAMロールポリシーを使ってクラスターに対する権限や アプリケーションの権限、どのタスクがどのAWSリスースにアクセスできるか タスク管理に関する権限 ECRからのイメージのpull Clone

Taskに関するセキュリティ Task単位でIAMロールを割り当て Task単位でSecurity Groupを割り当て

Taskでどのようにパスワードをわたすのか Parameter Store,Secrets Managerを使ってKMSに置いてTaskに設定されたIAMロールの権限に応じて秘密情報を取得

スケジューリングとタスクプレースメント 管理が必要となる2つのレイヤー - CountainerInstanceのスケーリング Fargateは考慮不要。 - Taskのスケーリング 　アプリケーションオートスケーリングを利用することでTaskのオートスケーリングを実現可能

EC2インスタンス使うときのスケールイン タスクの数が減る。→コンテナインスタンスを削除

Fargateのスケールイン

タスクのみがスケールインすればよい。

Target Trackingを利用したアプリケーションオートスケーリング メトリクスに対してターゲット値を設定 その値に近づくようにアプリケーションオートスケーリングが自動的にTaskを調整

Taksの配置を管理するには Taskga可動するために必要な条件は 必要なCPU、メモリ、ポートが割り当て可能化

どのようにTaskを配置したいのか 特定のAZに置く 特定のインスタンスタイプのみ

Task配置に関するロジック CPUメモリーポートとAZ、インスタンスタイプ、AMI　ID 配置戦略を満たすか 最終的なTaskの配置場所を決定

タスク配置例

コンテナインスタンスのroll out タスクdefinitionの更新時に新しいAMI IDを利用してコンテナインスタンスに配置する制約をつける 1ホスト1コンテナ distinctinstqnce constaraint + event stream + lambda