AWSSummit-Day2.md

２日目

[10:00-10:40] J2-01 知ってるIT部門は得をする！チームの満足度と業務効率化を一度に向上 ～メルペイ様に見るAmazonビジネスの活用方法～

• ちょっと遅刻していった

TL;DR

• Amazon Businessの紹介
  • 普通のAmazonの企業版
  • アカウントの一元管理や請求書などもまとめているので便利
  • しかも品揃えは普通のAmazonと変わらない
  • メルペイ社も使っているのでぜひ使ってみてね

詳細

Amazon Business

• 法人、個人事業主向けの購買専用サイト
• BtoCのサイトをベースとしているので、そこと同じく数億種類の商品がある
• 様々な企業が利用している

Amazon Businessの利点

• その前に、会社の中にある非効率なものとは？
  • アクセンチュアの資料では、非計画/突発的な購買(Tail Spend)が20％を占める
    • 例：マウスが必要になった、USBが必要、パーティの飾り付け、参考書が欲しいなど
    • Tail Spendは様々なところから突発的な購入をし、社員が立て替え、経費の精算をしているだろう。
  • この突発購買に関する問題
    • 金銭的なコスト
      • これは仕方ない
    • 買い物にかかるコスト
      • 商品検索、実店舗に行くとか
    • 処理に関するコスト
      • 建替精算とか
  • これらの問題をAmazon Businessは解決してくれる
    • 会社のアカウントを1つ作って、その下にぶら下げてユーザを作成、そのユーザの買い物履歴を紐づけて一括清算することで、立替の手間を省く
      • などなど
  • これで価格とコストの削減ができる(36%Down)
  • Amazon Businessは登録、利用が無料

メルペイ社の事例

• 対談形式
• どうやってAmazonBusinessをしったのか？
  • Amazonにそういうサービスがあればいいなと思って「Amazon 請求書」と検索したら出てきた
• 導入するまでの期間
  • チームでやるのはすぐに
    • 会社のアカウントを作らないといけないのでは？(疑問)
    • メルペイ社はチーム単位でもそのようなことをやっていいのかな？そうだとしたらすごい自由な社風が保障されているのか。(疑問)
  • 全社で展開するまでなら１ヶ月くらい
• どういうメリットを感じているのか
  • 導入ハードルが低かった
  • 配送時間の短さ
• メルペイ独自の使用法とは？
  • 全社員にアカウントを付与している。
  • 「社員を信頼するという考え方自体がひろまっているので、こういったことができているんではないかと思う。」

所感

• ただの宣伝では？あんまり聞く意味なかったと思った
  • AWSの事例紹介かと思っていったので、完全にこちら側の落ち度
  • ただ、これはこれで便利だとは思う

• メルペイ社の社風がAmazon Businessと一致しているのではないかと感じた

✨[11:00-11:40] B2-02 WindowsシステムをAWSで動かす勘所✨

TL;DR

• AWSには様々なWindows向けのサービスもある
• Windowsからの移行で問題となりそうなライセンスの形式もクリアできるような仕組み(テナンシー)を整えている
• 実際三層アーキテクチャを移行することを考えても、全てがAWSのサービスでまかなえてしまう

詳細

発表者

• AWS Japan技術統括本部ソリューショアーキテクト、松崎さん
  • 最新Windowsワークロードを対応サービス
  • 考慮する点、移行の際のポイントを喋る

Windows on AWSの最新動向

• 10年目で493％の伸び
• 143のインスタンスタイプ

Windows on AWSのメリット

• ワークロードのスケールが可能
  • ワークロードとはAWSを用いた一塊りのシステム
  • リージョンとAZ
    • SQL Serverを別AZに立てることで、同期コミット、自動フェールオーバーとかが実現できる
• 俊敏制の向上
  • フルマネージドサービス
    • EC2にSQL Serverを自分で立てるより楽
  • Amazon FSx for Windows File Server
    • フルマネージドのWindowsファイルサーバーサービス
    • 互換性が完全
• コストの最適化
  • WindowsというよりAWS全体のメリット
  • 既存のライセンスが使用可能なのはWindows独自
    • 組み込みライセンス
    • 持ち込みライセンス(BYOL)
  • テナンシーとライセンスのパターン
    • 共有ハードウェアインスタンス
      • いろんな人がいろんなマシンをいろんなライセンスで使う
      • Windows Serverはできない
      • SQLServerはできる(Software assuaranceが必要)
    • 専用ハードウェアインスタンス
      • Windows Serverはできない
      • SQLServerはできる(Software assuaranceが必要)
    • Dedicated Host
      • 完全に専用とする、どちらも持ち込める
• AWS License Manager
  • 調達したライセンスをどのインスタンスでどれだけ使っているかを徹底管理できる、逸脱しないかも見れる。
  • ダッシュボードから管理できる
• TSO Logic
  • データを元に解析をかけて、ライセンスの集約やインスタンスの最適化を行なった際のコストも計算してくれる

Windows移行を考えてみる

• 構成例
  • 典型的なWeb三層、アプリケーション、Web、DB、それぞれにLBやADとかIISがくっついている普通のシステム
• Active Directory
  • 移行するにあたり3点の形が考えられる
    • オンプレミスを直接参照
    • Amazon VPCにレプリカを置く
    • 全く別の別フォレストを置く
      • それぞれのメリットデメリットは一覧にしてある
  • 既存環境の移行はレプリカを推奨
  • 新しいワークロードをやりたい場合は別フォレストを推奨
• アプリケーションサーバ
  • 仮想マシンをそのまま移行できる
    • AWS Server Migration Service(SMS)
      • HyperVisorからVMのダウンタイムを最小化して移行を可能
    • CloudEndure(未紹介)
• 専用線とかロードバランサとかストレージとか
  • VPC,ELB,ECSとかが全部対応している
• どうやってマネージドサービスを持ってくるのか？
  • バックアップファイルの取得、S3へのアップロード、SQLServerへの復元(止められる場合)
  • 止められない場合のことは明日のセッションで
• 運用管理
  • パッチ適用ができる　AWS System Manager パッチマネージャーなどがある

• 所感
  • よかった、全部サポートしてやるからAWS使えっていうメッセージがひしひしと伝わってきた
  • Windowsにそこまで詳しくないので、実際に移行するとなるとさらに問題は発生するかも？

✨[12:00-12:40] B2-03 Amazon Workspaces の運用管理✨

TL;DR

• 仮想デスクトップであるAmazon WorkSpacesを大規模で使おうとすると、様々な問題が発生する
  • 自動化とか、監視とか、パッチ適用とか
• それらのソリューションを一つずつ解説。

詳細

発表者

• AWS Japan 技術統括本部 ソリューションアーキテクト　国政さん

Amazon WorkSpacesとは

• エンドユーザーコンピューティング
  • どこからでも好きなデバイスで企業内のデータとかにアクセスできるようになる。

• フルマネージド仮想デスクトップサービス
  • 「高額な初期投資はなし」などの様々なクラウドの利点が受けられる
• アーキテクチャの概要
  • 画像略
  • Direct Connect(専用線)やDirectory Services(AD on AWS?)とかを利用して、オンプレのActive Directoryや業務システムにアクセスできる
    • 全部クラウドでやる場合のみに使えるサービスだと思ってた(所感)
• だけども、大規模(数百台~)になってくると、セキュリティやデータの保全などの様々な運用上の問題が発生してくる。
• それらの問題に関するソリューションを解説

インフラ運用管理

• 様々なツール群が存在するので、適切なツール群を使用するのが大切になってくる。

• 手作業はめんどくさいので自動化を行いたい

  • Workspaces API/CLI
    • WorkSpacesへの操作を行える
      • CloudTrailを用いてロギングが行われている
    • ユースケース
      • デプロイの自動化
      • ステータスの収集
      • 接続情報の確認
      • 設定情報の変更
      • メンテナンスモードへの移行

• 監視、通知、モニタリングをしたい

  • CloudWatch
    • Metrics,Logs,Alarmsとかがある
  • デフォルトで取得できるメトリクスの一例
    • Unhealth…正常でない状態のWorkspacesに振られる
    • ConnectionFailure…接続失敗
    • InSessionLatency…セッションの遅延
  • これらのようなメトリクスを監視し、可視化を行う
  • ダッシュボードによる可視化
    • ベストプラクティスのダッシュボード構成が用意されているが、カスタムも可能
    • リソースのモニタリングには、CloudWatch Agentが利用できる。
      • Workspacesの中に潜り込ませてメトリクスを取得する。
  • ログインイベントをトリガに様々なAWSツールとの連携が行える

• インベントリの管理をしたい

  • CLIにより、どんなインベントリが存在するかを確認することができる。
    • ただし、数千数万とかになると流石にコンソールだと難しい
  • インベントリダッシュボードを利用
    • QuickSight+Athena+WorkSpaces API
    • ログイン情報をストレージ(S3)に入れてAthenaやQuickSightでダッシュボードを可視化することができる

• パッチの管理をしたい

  • WSUSやSCCMを継続して使うことがおすすめ
    • ソフトウェア配布時のネットワークトラフィックに注意
      • ソフトウェアの配布で専用線を消費してしまうため
    • AWSの上に管理サーバを持つことを推奨
    • WSUS、SCCMもAWSの上に

• バックアップはどうしよう

  • ネイティブでバックアップ機能を提供している
    • ドライブの役目が異なるので、Cドラ・Dドラを別々とするのがおすすめ、

• コスト管理をした

  • Cost Explorer

    • AWSリソース全体の管理ができる

  • 課金形態

    • Monthly
      • フルタイムの社員に向けたもの
    • Hourly
      • 80時間/月以下ならばこちらが向いている

  • WorkSpaces Cost Optimizer

    • 前月までの実績を取得して、最も安価な課金形態に自動変更してくれる。
    • これにより、ユーザーのエクスペリエンスが減らないかが心配

🤔[13:00-13:40] F2-04 いつからクラウドを活用していると錯覚していた？ クラウド戦略をドライブさせるベストプラクティス10🤔

TL;DR

• MobingiではAWSの請求を楽にするような製品を売っています。
• ベストプラクティスのうちの3つを紹介
  • クラウドに移行するだけで満足せずに、クラウドに最適化しよう
  • AWSの請求はすごくエンジニアの工数を削ってる、だから自動化しよう
  • コストを削減するためにAWSのに半数の企業はコスト分析をしていない、しよう

発表者

• Mobingi株式会社 丸山さん
  • スタートアップ企業、クラウドをカジュアルに有効活用できるように支援している
    • Ripple……請求を自動化するツール
    • Wave……コスト削減に必要なあらゆる情報を可視化

ベストプラクティス

• まずは、ベストプラクティスを一覧で紹介
  • 時間がないので10個から3個に絞って話をする

1. クラウドネイティブへのシフトを加速させる

   • クラウドの利点を手に入れる戦略
     • クラウドネイティブとはクラウドの利点を活かせるもの
   • これらの技術を採用していることの利点をちゃんと活かせているかが重要
   • Cloud Native Trail Map…クラウドネイティブ化へのステップ
   • クラウドで何使用している？というグラフを表示
     • 仮想マシン(EC2)が一番
     • コンテナは少ないのでクラウドを利用しているとは言えない(？？？？)
   • リフトアンドシフト
     • とりあえずクラウドにはリフトしたけど、アーキテクチャをシフト(最適化)できていないのではないか？
     • さっきのグラフから言えるんじゃないかな(EC2しか使ってないから)
     • コンテナとかサーバレスとかを使って、どんどんクラウドにシフトしていこう

2. 業務のリフト＆シフト

   • クラウドで増加した業務負担を対処する
     • 請求処理と経費処理が負担になっている
       • なんならエンジニアが請求処理を行なっている
     • マスターアカウントにまとめて来る請求データを分配する必要があり、それにはAWSの知識が必要なので、エンジニアが行なっている。
     • Excelを使ってAWSから来るCSVを解読している人が多い
     • 専用のツールがあるからそれを使った方がいいんじゃない？

• コスト分析

  • AWSユーザーの半数がコスト分析していない
    • なんでしていないの？
  • リーザブドインスタンス使おうね、安くなるし

• 最後に

  • クラウドに対応できるエンジニアの育成に注力してください。(これはマジでそう)
    • JAWS-UG
    • 勉強会参加
    • Re:Invent参加

所感

• ここら辺で嫌になってきたので聞いてない
  • コスト分析してないの？→やろうね
  • Excel使ってるの？→弊社のもの使おうね(そう言ってはないけど、言外からひしひしつたわってくる)
  • みたいな感じで、原因の深掘りが全くなかった.
  • 完全に宣伝セッションな気がする。
  • 最後の育成のメッセージは首を縦に振りながら聞いていた

[14:00-14:40] D2-05サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造

TL;DR

• Amazon Auroraの内部構造の説明
  • AZに分けて６個のデータを保存しているので耐久性が高い
  • それだけではなく、W/R、I/O、昇格の仕組み、などなどで様々な工夫をしているので、そのままのMySQLよりもパフォーマンスが高い
• 役にたつかはわからなかったけど、技術的にすごく楽しかった

詳細

• AWS本社の人
  • 同時通訳、英語の方を聞いてみる
  • Deep Dive、パフォーマンス、可用性について説明する

Aurora Performance & Scalability

• まず、Auroraがどうやって動いているか

• 3つのAZに2つのDBを置く、全て中身は同じ、そのため耐障害性が高い

• 特にサイズを指定することなく、10GBごとにスケールアップしていく

• 同時に書き込み

  • 書き込みの場合、4/6を満たさないとコミットされない、書き込まれなかったものはプロトコルを通じて、それぞれのDB間で通信されて同期がとられ、4/6を満たしたものから順次コミットされる

• AuroraのI/O構成、画像なので略

  • ホットログ、ACK、ゴシッププロトコルなどの用語が登場
  • 一旦ホットログに保持した後、DB間のギャップを特定…
  • Aurora MySQL は W/Rが5倍早い
  • バルクデータの読み込みは2.5倍早い
  • HardWareの高性能化によってAuroraも高速化

• ReadReplica

  • 読み込み専用のレプリカ、別にMasterが存在?
  • ReadReplicaを設定した場合、Masterノードが絶え間なく、ReadReplicaに書き込み続ける(同期)
  • Masterが死んだ場合、リードレプリカが昇格してMasterになる
  • ノードの下に、Shared distributed storage volumeという共通の基盤？があるのでそれをもちいて書き込み？

• MySQL vs Aurora I/O

  • 図があるけど略
    • 各ノードがEBSに書き込む必要があるため、
    • 普通のMySQLだと手順が多い
  • AuroraだとレプリカがEBSに書き込む必要はない
    • MasterがすでにSharedStorageVolumeに書き込んでいるので、
  • この構成により、早くなっている7/5倍？
  • MySQLは完全な変更、Auroraは差分的な変更
    • Shared Storageの存在がやっぱり大きい

• Aurora Read Scaling Options

  • Auto-Scaling
  • binlog レプリケーション

• Aurora Global Database

  • ８ヶ月前の機能
  • ディザスタリカバリのために、リージョンさえも変更して様々な場所に置いて、耐障害性をさらに高める
  • Masterノードがあるのは1つのリージョンのAZだけ　

• Aurora Parallel Query

  • Auroraには数千のCPUが存在するので、クエリ処理を並列化
  • あるタイプのクエリはデータの近くに置くことで、ネットワークトラフィックと待ち時間を削減
    • これマジですごいな(感想)
  • データは範囲分割されていないのでフルスキャンが必要など、すごい大変そう
  • NetFilxがテストしたところ、最大で１２０倍の速度になった、そのため、インスタンスのタイプをr3.8largeからr3.2largeに減らすことができた、コスト削減に繋がった。

• Aurora lock management

  • DBにはテーブルとか行をロックする必要がある
  • ロックチェーン？を全体ではなく、個々のものにすることで、高い更新スループットを実現した
  • よくわからない

• 可用性、

• クラッシュリカバリ

  • 普通のMySQLだと最後のチェックポイント(5分間隔)からログを遡るので、大量のディスクアクセスが必要
  • Auroraではストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで最適用することで早くなっている(原文ママ)
  • それぞれのディスクにREDOレコードとかが設定されてて、それを読み込むだけでできる？それを非同期にってやってるのかな？

• Cluser Cache Management(CCM)

• フェイルオーバー時のキャッシュの取得

  • 通常だとしばらく時間がかかる、CCMがないと、軌道に32秒、90%回復に340秒かかった
  • Auroraでは
    • 常にMasterとリードレプリカが同じキャッシュを持っている
    • CCMがあると32秒で９０％のパフォーマンスとなった

• Backtrack

  • バックアップからの復元を必要とせずに、データベースを特定の時点に戻すことが可能(すごない?????)
  • 時間がないので詳細は省略

• FastDatabase Cloning

  • データベースのクローンを高速に行うことができる

15:00-15:40 D2-06 AWSにおけるクラウドコンプライアンスの実践 ―セキュリティ担当者が理解すべき説明責任のポイント―(未完成)

TL;DR

• よくわからなかったので、途中で退席した
• NIST CSFのホワイトペーパーを元にお話しするらしい

詳細

• 話すこと

  • AWSのセキュリティポリシーと弊社のものと合わないという人と話をする時のポイント
  • AWSってどのようにセキュリティ管理をしているのか
  • グローバルなセキュリティスタンダードを理解しないといけないという人へのヒント
    • NIST CSFのホワイトペーパーの日本語版を紐解きながら

• こんなことがわかる

  • AWSは顧客のデータをどのようなものとして管理しているのか

• NIST CSFの活用:再構築より再利用

  • １からサイバーセキュリティの枠組みを作るのはものすごいコストがかかる
  • ITガバナンス
    • ビジネスの価値への貢献に対する説明責任
      • 管理に当たる物、セキュリティコンプライアンス
      • イノベーションROI
  • セキュリティも今やビジネス上の強みになる

• 今日の組織が抱える課題

16:00-16:40 C2-07【初級】Amazon EC2インスタンスタイプの選び方ガイド

TL;DR

• EC2に大量にあるインスタンスの違いを解説

  • プロセッサ、アーキテクチャ単位で異なるものが様々あり、いろんなニーズに対応できる
  • EC2インスタンスには命名規則が存在するので、それを理解するとわかりやすくなる。
  • 例えば、c5d.xlargeというものをあげると
    • c: インスタンスファミリー
    • 5: インスタンス世代
    • d: 追加機能、ないものもある
    • xlarge: インスタンスサイズ
    • を表す

• 何を使ったらいいかわからなかったら、一旦m(汎用的なもの)を使って、足りない機能をどんどんスケールアップしていこう

• AWS Japan 技術統括本部 ソリューションアーキテクト 小川さん

詳細

このセッションの目的

• c5d.xlargeの文字列の意味を理解できるようになる

インスタンスのラインナップを知る

• 最初はEC2の説明、初歩的だったため省略
• 選択できるプロセッサとアーキテクチャ
  • Intel Xeon processor
    • 一番早い
  • AMD EPYC processor
    • Xeonと比べて10%安い
  • AWS Gracition processor
    • ARMのアーキテクチャ
    • Xeonと比べて最大45%安い
• 選択できるアクセラレータ
  • NVIDIA
  • Xilinx
• Elastic Graphics
  • EC2にアタッチして利用するアクセラレータ
• これらのプラットフォームをかけ合わせると170くらいのインスタンスタイプが存在する
  • あらゆるワークロードとビジネスニーズに対応できる

EC2のネーミングポリシーを理解する

• c5d.xlarge
  • c: インスタンスファミリー
  • 5: インスタンス世代
  • d: 追加機能、ないものもある
  • xlarge: インスタンスサイズ
• インスタンスファミリー
  • 特徴を5つのカテゴリーに分類
    • 汎用
    • コンピューティング最適化
    • ストレージ最適化
    • メモリ最適化
    • 高速コンピューティング
      • GPUとか
• インスタンス世代
  • 数字が大きいほど新世代のものになる
• 追加機能
  • d:内臓のストレージが加わっている(インスタンスストア)
    • インスタンスストアとは、物理ホストに直接接続されているストレージ、固定
    • 高速I/Oが実現できる
    • インスタンスを止めるとデータが削除されるので、一時領域としての利用を推奨
  • n:ネットワーク強化
  • a:AMDのCPUを搭載
• インスタンスのサイズ
  • メモリ、CPUのスペックによって変わる
  • サイズが１段大きくなると、vCPU、メモリのサイズが倍になる、ついでに料金も
  • EBS、NW帯域に付いている最大というのはバースト時の最大性能を表す

補足情報

• 特殊なインスタンスタイプ
  • ベアメタル
    • ハードウェアを直接いじれるような環境を提供する
    • 独自のハイパーバイザとかエミュレータの実行など、ローレベルなハードウェア機能の利用におすすめ
  • バースト可能パフォーマンスインスタンス
    • 負荷に応じてCPUがバーストする
      • CPUクレジットという仕組み、ソシャゲのスタミナみたいなもの
    • 実際に使う際には色々と普通のものとは異なるので、注意が必要
  • ARMアーキテクチャ A1インスタンス
    • AWSが作ったやつ
    • 値段が少し安い
    • マイクロサービスや、キャッシュサーバなど多数の小規模インスタンスを動かす際に便利
• インスタンス起動の上限数
  • クラウド破産を防ぐため、上限が設定されている
    • 申請することで上限を緩和することができる

選定のポイント

• M(汎用インスタンス)を基準を重視するリソースから選択する
• それでもわからない場合には、一回使ってみて、何が足りないかでスケールアップしていく

17:00-17:40 [初級]AWSストレージサービス入門

詳細

• データを格納するサービスとして
  • EBS
  • FSx
  • S3
  • を説明

Amazon EBS

• EC2にアタッチして使うブロックストレージ
  • Cドライブ、Dドライブといったディスクのようなもの
  • API経由でボリュームを作成
  • SSD,HDDの選択肢
• アーキテクチャ
  • EBSに格納されたデータは、EBSサービス内で自動的に複製されて、高い可用性を実現している
  • EC2:EBS＝1:多のEBSアタッチが可能
    • 逆は不可能
• SSDの種類
  • IOPS
    • NoSQLなど
    • パフォーマンスが高い
  • 汎用SSD
    • アプリケーション、開発、テスト
• HDDの種類
  • スループットが高いタイプ
    • ログの処理、シーケンシャルな処理
  • ColdHDD
    • アクセス頻度が低いもの
• Elastic Volume
  • 今までの4つのボリュームの変更、ボリュームサイズの変更がダウンタイムなしで実行することができる
  • ここでデモ

Amazon EFS & Fsx

• EC2上でファイルサーバを利用することで一応利用はできたが、様々なコストがかかってきたのでAWSで用意

• マネージドサービス型のファイルサーバサービス

• EFS

  • ファイルの追加、削除に合わせて、自動的に容量を変更してくれる
  • アーキテクチャの図
  • ストレージクラス
    • 標準ストレージクラス(標準)
      • 日常的にアクセスするようなもの
    • 低頻度アクセスストレージクラス(安い)
      • あんまりアクセスしないもの
    • ライフサイクルポリシー(１週間で低頻度に…みたいなの)を適用することで、自動的に振り分けてくれる

• FSx for Windows Server

  • Windowsネイティブ互換
    • ActiveDirectoryの連携
    • SSDベースの連携
    • マルチAZによる高可用性
    • DFSによる大規模ファイルシステムも実現可能

• FSx for Lustle

  • Amazon S3とのシームレスな統合 �- Import/Exportで
  • 非常に多くものを分散処理するものに向いている
    • 機械学習とかハイパフォーマンスコンピューティングなど

• Amazon S3

  • どこからでもデータの保存と取得を行えるオブジェクトストレージ

    • イレブンナイン(99.9999999%)の可用性
    • 豊富なストレージクラスとライフサイクル管理
    • 分析系のサービスとシームレスにインテグレーションできる

  • ネーミングスキーマ

    • s3://バケット名/プレフィックス/オブジェクト名
      • プレフィックス＋オブジェクト名でキー名
    • 静的なウェブサイトのホスティングも行える

  • クロスリージョンレプリケーション

    • オブジェクトの作成、更新、削除をトリガーとしてリージョン間でのレプリケーションができる

  • バックアップ、アーカイブ、災害対策、クライドネイティブ、メディアの配信、ソフトウェアの配信

  • 全ての生データをS3にためておいて、データ処理という形で行える

    • セントラルストレージと呼ばれる