kglabo.blog

I will output what I thought.

「AWS Summit 2019」に参加してきました(1日目)#AWSSummit

どうもみなさん、おはこんばんにちわ!
ミナカワ(@yu_kgr)です。

2019/6/12 〜2019/6/14 に「AWS Summit 2019」というイベントがあり、AWSに対する理解を深めたかったので参加してきました。
当エントリはそのイベントの参加レポート(1日目)になります。

f:id:kgr0210:20190615022753p:plain

#1. 基調講演:デジタル変革の最前線で選ばれ続けるクラウドへ~ デジタライゼーション時代のカスタマーサクセス ~

  • 登壇者(敬称略) : 長崎 忠雄(AWS Japan - 代表取締役社長 )
  • 備考 : この基調講演では長島さんより「現在のAWSを取り巻く状況」についての説明があった後、このAWS Summitで日本のお客様にクラウドコンピューティングの最先端を知ってもらい、テクノロジーを学んでもらう場として活用してほしいとの話がありました。

概要

  • 今年度AWSは、四半期1Q時点で3.3兆円で年間成長率 41%!
  • まだまだ新しいリージョンを建設していく模様
  • 国がクラウド推進を後押ししており、我々はAWSを学ぶ場をどんどん増やしていく
    • スタートアップ企業を技術で支える「AWS LOFT」
    • 開発者向け最先端テクノロジーの学びの場「DEV DAY」
    • パートナーと共に共同で全国を回る企画も10月から開催
    • オンラインで学習できる「AWS INNOVATE」
  • 国内でのパートナー企業も750に増加した
  • 教育機関や学生に対して「AWS Educate」を無料展開して学べるようにする。
  • 上記を修了した人材を企業に紹介斡旋していく事も考えている。
  • 機械学習、強化学習を遊んで学べる「AWS DeepRacer」をIntelと共同開発した。

ゲストスピーカーの方々の話も下記のような話をされていた。

  • ここ数年でハード主体だったものがソフト主体に変わってきている。
  • いかにプロダクトに対してフォーカスした開発を行って価値を出すかが大事。
  • そのためにAWSをどうやって活用するかという所。

所感

余計な仕事を減らして注力したい事に集中するためにはAWSをうまく活用する事が重要。
AWSを学ぶコンテンツやイベントは、非常に豊富に存在しているのでどんどん活用していくと良さそう。

#2. ドコモが実践している「ユーザ視点のサービス開発」と「高速リリース」を実現する組織の変革

  • 登壇者(敬称略)
    • 三井 力(株式会社NTTドコモ - サービスデザイン部 担当部長 )
    • 小西 慧(株式会社NTTドコモ - サービスデザイン部 システムアーキテクト)
    • 車谷 駿介(株式会社NTTドコモ - サービスデザイン部 システムアーキテクト)
  • 備考 : このセッションでは、ドコモのお三方によりAWSをより使いこなす組織への変革(準内製、アジャイル開発、自己組織化、マネージド化推進等)の取組み事例と効果についてのお話がありました。

概要

  • これまでの開発は無駄が多くやるべき事ができていなかった
  • 理想の形に近づけるため「自分たちでやる」ようにしていきスピードを獲得
  • AWSを活用しプロダクトの価値を向上させる事に注力していく形にしていった
  • 社内で組織を変革するための活動を行った
    • 方向性、働き方の共有
    • UXについてビジネスサイドを巻き込む
    • 高スキル人材の確保、モチベーティブな社員の投入
    • 権限の付与
    • 独自の表彰制度
    • プロトタイピングが行いやすい環境構築
    • 他社の意識、勉強会参加支援
    • データ解析ツールの利用(BIツール)
    • コミュニケーションツール導入(Slackなど)
  • 結果「開発者」「オペレーター」「ビジネスサイド」全てに良い影響が出た
    • DEVは、すぐ試せるすぐ捨てれる、少人数・短期間で済むようになりモチベも向上
    • OPSは、オートスケールで運用コスト低下、ログ調査もElastic Search
    • BIZは、サービスやマーケ手法に対して敏感になり、現場からプロトタイプ提案で商用化されるケースも出た
  • チームを変えるためには「ファーストペンギン魂」が大事
    • まずは「CloudWatchEventをSlackに連携する」ぐらいの一歩でも良い
    • 小さくやっていき「普通」にすることが大事

所感

セッション中、AWSの事を「勝手に成長していく武器」と言っており印象的でした。 データ解析ツールに関してはまだうまく利用できていないので活用していきたいです。 ちなみにAWSから来るびっくり費用に関しては「人/月」換算すると気持ちが楽になるとの事。

#3. AWS Storage Services の特性理解と選択指針

  • 登壇者(敬称略): 川野 純(AWS Japan - 技術統括本部SA)
  • 備考 : AWSの各ストレージの特徴を把握するための指標を整理して特徴・構成などを理解し、適切なものを選択できるようにするためトピックについてご紹介いただきました。

概要

大前提としてストレージにはいくつか種類があり、I/O特性やストレージ特徴を表す「7の指標」が存在する

ワークロード

さまざまなワークロードにおいて、求められるI/O性能が異なる (ちなみにワークロードとは「AWS リソースと、ビジネス価値をもたらすコード (顧客向けアプリケーションやバックエンドプロセスなど) の集まり」という意味)

  • DB 用途
  • HPC/機械学習 用途
  • バックアップ 用途
  • Data Lake 用途

ストレージの種類

ストレージも複数の種類が存在している

  • ブロックストレージ(EC2 / EBS)
  • ファイルストレージ(EFS / FSx)
  • オブジェクトストレージ(S3)
どう選択すればよいか

これらを選択する際に参考になる指標としては、

  • 耐久性(堅牢性)
  • 可変性(データにアクセスできない期間がどれだけ許容されるか)
  • セキュリティ(どれだけ不正対策が必要か)
  • 拡張性(どれだけ容量を拡張できる必要があるか)
  • パフォーマンス(IOPS / スループット / レイテンシ)
    • スループット(転送能力)は「オブジェクト > ファイル > ブロック」の順で高い
    • レイテンシ(通信遅延)は「ブロック > ファイル > オブジェクト」の順で少ない
  • コスト
  • アクセス方法(ローカル or 専用プロコトル or API?)

という感じ。

ファイル関係のマネージドサービスには「データ管理とセキュリティ」「データの移動」「データの格納」というカテゴリ毎に適したサービスが存在しているが、本セッションでは「データの格納」にスポットを当てた内容とする。

プロックストレージについて

ブロックストレージ(EC2 / EBS)には、下記の三種類が存在している。

  • インスタンスストアのストレージ
  • SSDのブロックストレージ
  • HDDのブロックストレージ

これらはインスタンスサイズやタイプの違いが存在しており、適切なものを選択する事でコストの最適化を行う事が可能。(xN.largeとかのやつですね)

  • ちなみに先月新機能として[クラッシュ整合性スナップショット]というものが追加されたとのこと。
ファイルストレージについて

ファイルストレージ(EFS / FSx)のアーキテクチャに関しては、

  • マルチAZでデータは暗号化、セキュリティグループを用いてアクセス制御可能
  • パフォーマンスIOリミットが100%を超える場合は最大I/Oモードを選ぶとよい
  • 即時整合性はあるが、3秒程度あるので気をつけること
  • EFS低頻度アクセスという機能がリリースされたので、127KiBかつ、30日間アクセスされていない場合は低コストな保存形態にしてくれるようになったらしい
オブジェクトストレージについて

オブジェクトストレージ(S3)は、いわずもがなファイル単位でI/O出来るネットワーク・ストレージで耐久性、可用性、拡張性が高いのが特徴。 他とは違いアプリケーションからの利用が意識されているので、HTTPプロコトルでアクセスしたり、URLを割り当てる事が可能なため、静的ファイルなどを配置する事が多い。

  • ちなみにアーカイブに特化したAmazon Glacierというサービスも存在している

まとめ

  • 様々な特徴を持ったストレージが存在しているので、ワークロードによってどの指標を優先していくのかを考えることが大事。
  • また、1つのアプリケーション内でも複数の異なるストレージワークロードが存在しているので合わせて意識すること

所感

恥ずかしながらストレージに関しては「ファイルを入れる所なのでは」ぐらいの認識しかない状態でしたので、このセッションを聞いた事で「全体的な引いた目で見るとEC2やEFSなどもデータいれる所だな」とリフレーミングする事ができました。

更に言うと、その各々の特性を持ったデータの保存形態、特性によって適切なマネージドサービスを選択することで、 適したパフォーマンスを発揮するうえ、コスト最適化も行えるので素晴らしい。

#4. Edge Servicesを利用したDDoS防御の構成(AWS WAF/Shield)

  • 登壇者(敬称略): 中谷喜久(AWS Japan - 技術統括本部SA)
  • 備考 : DDoS耐性を高めるための「AWS Shield」と関連サービスについてご紹介いただきました。

概要

  • 「インターネット」はASPの集合体であり「インターネット」自体は存在してない
  • 元々は軍事目的で利用されていたので「遅くても通信できれば良かった」
  • アプリケーションもサービスに接続するために複数の行き、帰りの通信を行う必要があり安定しづらい

Edge Serviceはこの安定し辛い通信をユーザに近い所でネットワークを提供するサービスで、 今回名前が出ている「WAF」や「Shield」はRegionに対してのサービスである。

リージョン内で動くアプリケーションに対してDDoS攻撃を食らった際、防御してくれるものが「AWS Shield」で、DDoSも一箇所で防御するのではなく複数拠点で分散したDDoS防御を行ったほうが良いよねという感じらしい。尚、WAFと併用が可能。

AWS WAFとは

  • CloudFrontとALBに配置してDDoS対策を行う
  • L7防御

AWS Shieldとは

  • 上記に加えて「EC2、ELB、Global Accelerator、Route 53」も含むDDoS対策
  • StandardとAdvancedのプランが存在。AdvancedだとL3/L4防御も追加されてエンタープライズ寄りの要件を満たすようになる

DDoS Resilient Reference Architectureというアーキテクチャ

これは「敵から城を守るため、事前に堀や平垣を用意する」という下記のような考え方

  1. DNSに攻撃が来るのはDNSのWAFで守る
  2. しかしDDoS攻撃を検知するまではアプリ側で耐える事になるので、オートスケール等で対処するようにする
  3. 適切なCloudWatchモニタリングを行ってアラート設定を行う
    • この時、帯域だけではなくCPU使用率なども確認するように

ただ「耐えてる間の費用どうにかしてほしい」という意見もあるので「AWS Shield Advanced」が有用。

AWS Shield Advancedの特徴

  • 検出・モニタリング項目の追加
  • 大規模なDDoS攻撃からの保護
  • 攻撃検知、緩和状況の可視化
  • WAFとFWマネージャーが無料で利用できる
  • 24x7 DDoSレスポンスチームと対話できる
  • コスト保護(DDoSによるコスト吸収)
    • AWSが推奨するアーキテクチャで構成している場合、インスタンス側でオートスケールして耐えた金額を返金する(!)
  • 対象となるサービスは、
    • DNS、Route53、Webアプリ、CloudFront、ALB、etc…

設定自体もウィザード形式なので保護したいリソースだけ選択する事が可能。

  • WAFとの関連付け
  • 攻撃を検知した場合にどのSNSに送信するかの選択
  • ベースラインを指定しておけば閾値を超えた場合にDDoSだと判断
    • なんの対象に対して防御するのかなどウィザード側で考慮
  • 「どのような攻撃が」「いつどこから」なのかを見ることが可能
  • 新しいDDoS攻撃手法が来た場合も自動でアップデートして対処

所感

(普段、DDoSを意識して生活した事がないので Digital Attack Map を見てみたら予想以上に身近な存在だった)

今回、このレポートをまとめながらDDoS攻撃に対して「AWS WAF」と「AWS Shield」をどう利用するかという事を理解する事が出来ましたが、Advancedにする場合は1ヶ月に3000ドル掛かる事らしいので、コストとの兼ね合いでどこまで強力な対策を行うか?という所になるのかなと思いました。

#5. AWS Systems Manager 徹底活用 ~エンタープライズのユースケースから~

  • 登壇者(敬称略) : 大村 幸敬(AWS Japan - 技術統括本部SA)
  • 備考 : エンタープライズ企業で発生する複雑な運用ユースケースの紹介と、AWS Systems Manager を使って運用を実現する具体的な方法についてのお話がありました。

概要

基本的にビジネスアジリティとガバナンスコントロールとしいうものは、二律背反だがAWSであれば実現できる(!)

まず、AWSをコントロールプレーンとして、運用管理に使用する方法としては「System Manager(SSM)」を活用する。

これは、AWSとオンプレのサーバ群を管理する多機能なツールセットでユースケースとしては「可視化」「一括オペレーション」などに向いている。

可視化のケース

例 : 社内のサーバのJavaバージョンの比率をグラフ化したい場合
  • 要件としては下記
    • オンプレミスもクラウドも対象。野良サーバも含む
    • 全サーバのソフトウェア構成をキーワード集約してグラフ化

これは「SSM Agent」を各サーバに導入すれば可能で「SSM Inventory」がキーとなりS3に集約してくれるので、

  • 「S3」→「Athena」→「QuickSight」という流れで確認する事ができる
  • Agentにポリシー(お札)とロール(帽子)をつけてVPCに導入すればSSM Agentが SSM APIにポーリングする。
  • オンプレに対しては、VPC Endpointが対応しているので、そこに対してCloudWatch AgentとSSM Agentを導入すればOK

「SSM Agent」から「SSM Inventory」にデータが導入されるので、それを「Athena」に渡して「QuickSight」で閲覧する事で実現できる。

一括オペレーション

例1 : サーバ群に対して規定操作の一括実行を行う場合
  • リソースグループ(タグによるサーバ群のグループ化)に対して「SSM Run Command」を実行する事で一括実行する事が可能。
    • Agentが入っていてポーリングしているのでssh接続等をする必要もない
例2 : オペレーターによる規定の回復オペレーション

これは障害を検知すると戻す作業を実行したいが、クラウドの場合はAWS知見がある方じゃないとオペレーションできないのではないかという問題が出る。

  • 対応としては、オペレーターの運用端末にbatファイルを用意。
  • このbat内にAWS CLIのコマンドを記載しておき「SSM Run Command」や「AWS API」を実行する事が可能なのでオンプレ時の対応時と変わらない形にできる
例3 : サーバログイン操作の事前許可、事後確認など : ガバナンス

サーバにログインする際にいちいち申請だったり、何を行ったのか等の記録を行わずともセッションマネージャーという機能を利用すれば解決できる。

  • 申請に基づき、IAMポリシーを作成して「x時からx時まで、どのインスタンスに接続可能」と申請して、セッションマネージャーでサーバへシェルアクセス
  • これで操作ユーザ、対象サーバのログ、具体的な操作ログも調査する事が可能

「SSM Maintenance Window」を利用すれば決まった時間に指定した処理を複数に対して実行する事が可能。

  • インタタンススケジューラーという決まった時間帯だけ起動するものも存在している。
  • サーバーの上げ下げをどうするか検討する場合はこちらのほうがコストも低いのでまずは、こちらを採用してみるのが吉

サーバ群のメトリクスとログを集約管理したい場合は「OSメトリクスを一括して収集、監視、サーバのログを一括して集約」

  1. CloudWatchAgentの設定ファイルを生成して、SSM parameter Storeにいれる
  2. Run Commandで実行してSSM経由でparameter Storeの設定配布、CloudWatch Manager Agentを実行できる
例 : セキュリティパッチの適用徹底について
  • 適用状況を一括で把握して一定のルールで全社のサーバに適用したい
  • SSM patch マネージャーというものがあるので、それを利用して、patchをDLしてSSM maintenance window => SSM Run Commandを実行できる
例 : ライセンス管理をしたい
  • 所有ライセンス数と実際の利用数を管理したい
  • license manageというものがあるので、そちらをうまく使う(雑)

Systems Manageは基本的に無料だが色々と便利に利用する事が可能。

大体のケースでAWSの運用管理ツールを利用して解決できるので、気軽にSAにユースケースを相談してほしいとの事だった。

所感

Systems Managerの機能だけを聞くとイマイチピンと着ませんでしたが、今回のセッションでユースケースをいくつか聞いたことによって似たような事例が発生した時に「あ、これSSMで解決できるのでは?」という思考が出来そうだなぁという雑な感想が浮かびました。

#5. Security Best Practices on S3

  • 登壇者(敬称略) : 焼尾 徹(AWS Japan - 技術統括本部 SA)
  • 備考 : Amazon Simple Storage Service (S3)を利用するにあたって、AWSで最優先事項となるセキュリティについてどのように考えればよいのかについてお話していただきました。

概要

S3が何者なのかは「3. AWS Storage Services の特性理解と選択指針」で説明しているので割愛。

まず、S3にデータが格納されるシーンとしては「アプリケーション」や「移行やバックアップ」が考えられるが、ユースケース毎に分類するとこのような感じとなる。

  • データ保護・移行
    • バックアップによる活用
    • データ移行
    • サーバマイグレーション
  • データレイク
    • 取り込み・加工・活用での利用
    • データ分析基盤
    • 機械学習・IoT
    • HPC・映像処理
  • Webサービスのコンテンツオフロード
    • WebサーバからDBを介して非構造データとしてS3への格納
    • 写真管理サイト
    • 動画サイト
    • ECサイト

AWSでデータの安全確保をサポートする方法は「最小権限の原則」で、この原則を実行していくために適切なアクセス許可の定義は何なのかを整理する。

  • IAM(人の管理)
  • VPC(仮想マシンの管理)
  • S3(資産の管理)

IAMユーザーポリシー

  • このユーザはAWSで何が出来るのか
  • 例えば。S3に対してPUT / GETは可能などを指定すること

Amazon S3 パケットポリシー

  • このS3リソースに誰がアクセスできるのか
  • どのユーザーからバケットにアクセスできるのか

基本的に下記のフローを通してS3がリクエストを承認するかを判断する

  1. 全ての決定は拒否から始まる
  2. 該当ポリシーすべてを評価する
  3. → 明示的な許可があるかどうか
    • 許可がない場合は拒否される
  4. 許可がある
  5. 最終決定のデフォは拒否
    • 明示的に許可すること

偶発的な情報開示にはどう対処するか

対策として挙げられるのは「IAMによる適切な権限管理」「VPCネットワークの理解」など

また「S3 Block Public Access」を利用すると良い。 これはアカウントレベル、もしくはバケットレベルで「あらかじめ」パブリックになることを防ぐ機能で、パブリックにアクセスできるような設定行為を抑制する。

  • 前から利用しているバケットを流用した時など、現在は問題のある設定になっていた場合にアクセスを無効化してくれる。
  • これは自動推論という数学的な考え方でセキュリティを実現している

S3における暗号化として、サーバー側の暗号化 (SSE) とクライアントサイドの暗号化(AWS KMS)利用しよう。

データの不整合 / 過失による削除にどう対応するか

「IAMによる適切な権限管理」と「データの整合性チェック」「MFA Delete」など

これをどう防ぐかは「バージョニング」と「Object Lock」が有効。
Object Lockとは改ざんの防止機能。

  • S3 Objectを変更できないようにする(Object または bucketに対して適用)
  • リテンション指定
    • 改ざんを防止するロック期間の定義。リーガルホールド
    • 監査が入って内容を見るときなどに利用できる
  • データ保護とコンプライアンス
    • 第三者機関にわるSEC 17a-aアセスメント済み
    • 意図しない削除からの保護
  • 2つのモード
    • コンプライアンとモードとガバナンスモードが存在

認証の取得、ユーザー行動の変化を観察したい

これは「AWS Cloud Trail」によるログ取得を行う。

  • 「いつ、誰が、どんなAPIをコールしているのか」を取得する事ができる
    • セキュリティとしても、トラブルサポートにも利用できる
  • S3バケット、オブジェクトに対してPUT/GETしたというログ(データイベント・管理イベント)を記録する。
    • AWSアカウント1つで100個までバケットを用意できるので、用途に合わせたバケットを別々に用意するようにする。バケットを何でもかんでも合わせないこと。

「Amazon Macie」によるユーザ行動の追跡もあり。

  • 機密データを検出、分類、保護するための機械学習によるセキュリティサービス
  • S3などでも利用できるようにデザインされたもので、個人識別情報が存在しており機械学習で通常とは違うアクセスがあったりした場合に通知・イベントを発火させる事が可能

インフラストラクチャの可用性

  • これにたいしての対策としては「S3の可用性」「ストレージクラスの理解」「クロスリージョンレプリケーション」などが挙げられる。

これらを振り返ると

  • S3はシンプルだが多機能
  • セキュリティ要件 / データの格納要件を考えて適切な利用を行うこと
  • 基本は「IAM」「VPC」「S3」

という事でした。

所感

S3にデータを保存するにあたって、何を考えないといけなくて何が駄目なのかを説明した後、ケースごとに対処方法とやるべきことを解説してくれたのでわかりやすい内容でした。

そして、安全が関わると絶対「IAM」が出てくるなぁという印象。

#6. AWS コスト管理徹底入門

  • 登壇者(敬称略) : 伊藤 裕史(AWS Japan - 技術支援本部 テクニカルアカウントマネージャー)
  • 備考 : AWS利用状況をコストの観点から見える化して把握・管理し、投資効果を高めるための方法を解説していただきました。

概要

まず、AWSの特徴としては下記があげられる。

  • 初期投資が不要
  • サービス開始後、69回の値下げ
  • 利用しただけの支払い
  • 利用はセルフサービス
  • スケールアップ・ダウンが可能
  • 進化し続けるインフラ

コスト管理のためになにをすればよいか?

  1. 可視化
  2. 監視・分析
  3. 最適化

このサイクルをぐるぐると回していく

1. コストの可視化

コストを可視化するには何をすればよいのか?
確認が必要な単位としては、

  • アカウント
    • ひとつのアカウントだけではなく、環境、用途毎に様々な用途に合わせたアカウントがあるはず。これは AWS Organizationsを利用
  • AWSサービス
  • アプリケーション
    • アプリケーション毎に管理。これはコスト配分タグを利用。
  • 利用用途のタイプ
    • コストをGUIで確認していく
AWS Organizations

複数のアカウントの利用料金をまとめて確認する事が可能。
基本的には統合管理アカウントを作成して、そこから子アカウントを作成して個別に管理していく。

コスト配分タグ

AWSのリソース(ECインスタンス毎)にタグを設定可能。
タグをコスト配分タグとして設定する事でコスト把握に利用可能(Key = Valueの形式)

  • Name : Web / System : Front
  • Name : App / System : Front
  • Name : DB / System : Front
  • Name : MasterDB / System : Master
コストをGUIで確認 - AWS Cost Explorer

コスト可視化ツールの入り口は、請求ダッシュボード。
どのサービスでいくら利用されているのかをGUIで確認する事ができる。

  • フィルターを活用するとタグ毎に確認する事も可能
  • 請求書は、CVSでもPDFでもOK

2. コストの監視、分析

そもそもコストの監視・分析をする目的とは下記を確認するため。

  • 想定外のコストが発生していないか
  • 無駄なコストが発生していないか
  • コスト最適化できる余地がないか
「AWS Budgets」というサービスがある
  • これは、想定外の利用増加を監視するサービス。
  • 予算の概要を設定すると、様々なフィルターで管理の粒度を設定できる。
    • EC2は50%までーみたいな。
    • 実利用なのか、予測なのかを設定
    • 通知のしきい値を設定
    • メール?SNS?どちらに通知するのかを設定
「AWS Trusted Advisor」も忘れられない
  • ベストプラクティスだと考えている構成と実際の利用状況を比較できる
    • (全ての項目を確認する場合はビジネスサポート以上の契約が必要)

3. コスト最適化

コスト最適化に対しては下記のアプローチを考える

  • ボリュームディスカウントの活用
  • 購入オプションの活用
  • アーキテクチャの最適化

所感

いち時期、学習目的でFargateを触っていたら会社から支給された実弾演習アカウントの月額金額が100ドルをオーバーした事があったので、Lambdaで毎日Billingの情報をLineとSlackに通知するようにしましたが、今回教えてもらったサービスも活用してみたいと思います。

#7. AWS におけるシステム運用管理の自動化

  • 登壇者(敬称略) : 橋本 拓也(AWS Japan - 技術支援本部 クラウドサポートエンジニア)
  • 備考 : AWS Systems Manager、AWS Config、Amazon CloudWatch などを活用して、人の手を煩わせずに AWS 上に構築したシステムを運用・管理するための基本的なノウハウをお話しいただきました。

概要

基本的にはこんな感じの話。

  • AWS Systems Managerでハイブリッド環境のサーバ運用を自動化
  • AWS Configでリソース変更を追跡
  • AWS CloudWatchEventでの自動反応

ガバナンスとアジリティ

二律背反であるガバナンスとアジリティをどう担保するか

  • ガバナンスの担保
    • モニタリングされている
    • 管理・監査できる
    • レポートが見れる
  • アジリティの担保
    • 実践できる、挑戦できる
    • 制作性がある
    • 変化への追従が容易

自動化によって解決できる運用の課題は下記。

  • 厳密に運用するほど、人的コストが増大(Cost)
  • オペレーションミスが避けられない(Quality)
  • Eventの検知と対処にタイムラグが存在する(Delay)

これらをAWSのマネージドサービスで解決していくが、何を自動化するのかを慎重に検討すること。
当てはまるケースとしてはこんな感じ。

  1. 単純な作業
  2. 手順が固まっている
  3. 何度も発生する

AWSで運用自動化を担うサービス

  • CloudWatch - リソースとアプリケーションを監視
  • Config / Cloud Trail - ユーザの操作、リソース設定を継続的に簡素
  • SSM / リソースを管理してオペレーションを実行する
  • コスト最適化

SSMでハイブリッド環境のサーバ運用を自動化

  • SSMに関しては前のセッションで聞いたので割愛 :-(

所感

1日目だけで、SystemManagerの話題がわんさか出てきました(自分がそこ狙って聞きに行ったからだけど)

Day1最後のセッションゆえ、終盤あたりで私の集中力が途切れてしまったのですが、 資料が公開されたら「AWS Config」「Amazon CloudWatch」の活用方法について改めて確認したいと思います。

1日目の感想

今回初めてAWS Summitに参加しましたが、予想以上にお祭り感がすごくて驚きました。 基調講演の時点で謎の感動でモチベーション向上。

1日目は休憩時間も地蔵と化してメモを取るだけになっていたので2日目移行はアクティブに動き回ってました。 2日目の感想ではそちらにも触れたいと思います。

他の日程のレポート

1日目のレポートはこちら

blog.kglabo.com

2日目のレポートはこちら

blog.kglabo.com

3日目のレポートはこちら

blog.kglabo.com