AWS Summit Tokyo 2019 / Day2
幕張メッセで開催されたAWS Summit Tokyo 2019のDay2に行って来ました。
AWSは軽くかじった程度の知識しかなかったので、取り敢えず理解できそうなセッションをひたすら予約して臨みました。
9:30 会場到着
会場は大盛況でした。
この手の大きなイベントはJaSST Tokyo以来なのでちょっと面食らいました。
10:00 コンテナ化されたアプリケーションのAWSでの構築・運用指針
正直英語のセッションだったのと、一発目のセッションで眠気から覚めていなかったのであまり内容を覚えてないです←
メモも酷い有様だったので、拾える範囲で書きます。
コンテナ技術とDevOpsの話からセッションが始まりました。
そこからECS(Elastic Container Service)やらAWS Fargateやらの話に続き、サーバーレスの特性について述べられました。
その後のセッションでも度々語られるのですが、AWSは基本的に「煩わしい部分は全てAWS側で管理しますからアプリケーションの開発に注力してくださいな」って感じのスタンスみたいですね。
柔軟性とシンプルさのバランスはワークロード単位で考える。
この辺りから記憶が曖昧です。
メモの内容をかいつまんでいきます。
AWS App Meshを使うとアプリケーションからネットワークの設定ができるとか何とか。
「アプリケーションをもっと前に、インフラをもっと後ろに」とのことでした。
どうもマイクロサービスを活用するときに、アプリケーション側からネットワーク構成を管理できるみたいですね。
もっとよく調べてみたいです。
最後の方は、ECSの実際の活用事例として、米国マクドナルドのフードデリバリーやGoDaddyが挙げられていました。
11:00 「地球上で最もお客様を大切にする企業」のイノベーションカルチャーとは
Amazonの文化について。
ちょっと内容が濃かったのでメモをベタ貼りします。
## ミッション
地球上で最もお客様を大切にする企業であること
## イノベーション
私たちは、お客様体験を起点に逆算して考えます
制約(ブロッカー)をどう乗り越えるのか
どういう潜在的なニーズを持っているのか、フィードバックをもらう、声を聞く仕掛けを埋め込む
根拠に基づく形で意思決定をしたり優先順位をつけたり
これからの10年、何が変わるか？
よりも
これからの10年も、何が変わらないか？
Amazon MARS(ML、etc...)
最終的にはお客様のニーズに行き着いた
成長の原動力
- 価格 Price
- 選択肢 Selection
- 利便性 Convenience
お客様体験→顧客数→出店社→品揃え→お客様体験
低コスト体質・構造→低価格→お客様体験
イノベーションによって、お客様のあらゆるシーンを楽に豊かに
イノベーションカルチャーを支える仕組み
- カルチャー
- メカニズム
- 組織
- アーキテクチャ
### カルチャー
Our Leadership Principles
(原理・原則14ヶ条)
社員一人ひとりがミッションを実現するリーダー
Bias for action
ビジネスではスピードが重要
多くの意思決定や行動はやり直すことができるため、大掛かりな検討を必要としない
1Way or 2Way
そのドアは一方通行？それとも戻ってこれるドア？
### メカニズム
5つの問いかけから始まる
- 対象のお客様は誰？
- お客様が抱える課題や改善点は明確？
- お客様が受けるメリットは明確？
- お客様のニーズやウォンツをどのように知った？
- お客様の体験が描けている？
Working Backwards:文書化し、すばやく実験する
プレスリリース(PR)
FAQを作る
ビジュアルを作る
≒顧客体験の紙芝居
プロトタイピングする
7割書いたら一旦共有→フィードバックを集めてブラッシュアップ
読むことから始め、議論し、質問を投げかける
### 組織
Two-Pizzaチーム
2枚の大きなピザで全員がお腹いっぱいくらいの規模感
スピード・俊敏性
小さくそれぞれが自律的に動ける組織
何を作るかから実行までのすべての権限を持つ
主体性と自立性を重視
実験は早めに、頻繁に、また、繰り返し
### アーキテクチャ
マイクロサービスアーキテクチャ(疎結合)
- 単一目的のサービス
- すべてのサービスは個別のAPI経由で接続
- 大部分が互いにブラックボックス
- API経由でのみアクセス可能なビジネスロジックとデータ
AWSでは約170のマイクロサービスを用意
セルフ・サービスプラットフォーム:好きなもの、好きなとき、好きなだけ
Builderたちが、適材適所で使えるデジタルツール
約95％が「お客様の声」から、具現化されている
5000万[デプロイ/年]を支えているプラットフォーム
1日あたり140のデプロイ
22リージョンにクラウドのセンターがある
これからも拠点を増やす、サービスを増やすことに注力する
## 足跡
AWS
2006年以来の単価の値下げ回数:71回
2018年度に導入した新サービス・新機能:1957
AWSの提供するクラウド化支援サービス
プロジェクト→ファウンデーション→マイグレーション→リ・インベンション
イノベーションの実現
- 新技術を活用した新たなビジネスの創出
- トライ＆エラーを繰り返しながらの多くの実験
既存IT資産の移行
- IT関連コストの削減
- 運用開発生産性の向上
## AWS Loft Tokyo 〜挑戦をカタチにする場所へ〜
- Ask An Expert カウンター
- コワーキングスペース
- セミナーやイベント
**ビジネスイノベーションの第一歩をAWSとともに**
主体性と自立性を重視しているところは、シンパシーを感じました。
12:00 re:Invent 2018のアップデートまとめとre:Invent 2019の紹介
ランチセッションだったので、簡単な昼食とお茶が配られました。
かんぴょう巻きといなり寿司、美味しかったです。
セッションはre:InventとAWS Summitの共通点・相違点や、昨年のre:Inventの様子の紹介から始まり、程なくしてアップデート情報の紹介が始まったのですが、怒涛の勢いで様々なサービスが紹介され、正直メモを取る余裕があまりありませんでした……。
個人的にAmazon Quantum Ledger Database(QLDB)とAWS Outpostsは面白そうだと思いました。
re:Invent 2019が今からとても楽しみです。
13:00 休憩・企業ブース巡り
セッションを予約せずランチタイムとして確保しておいたのですが、12:00のセッションでお昼が配られたので、折角なので企業ブースを回ることに。
Veeamという仮想マシンのバックアップ・レプリケーションソフトとAWSの連携について聞かされたりしてました。
ノベルティも少々貰ったり。
14:00 サービス責任者が語るAmazon Aurora MySQL/PostgreSQLの詳細と内部構造
僕が参加したセッションの中では一番面白かったです。
Amazon Auroraの内部構造のお話。
こちらも内容が濃いのでメモをベタ貼り。
そのうち動画が公開されたら改めて見直したいと思います。
## Amazon Aurora
- 性能と可用性
- シンプルさとコスト効果
- MySQL、PystgreSQLと互換性がある
- 利用した分だけお支払い
### 性能
Shared Storage Volume
ストレージボリュームがデータベースに書き込む、ストレージに書き込む、という部分を行っている
それぞれのAZに2つずつ、計6つのデータのコピーを保存することでAZ+1の障害に対応
データは10GBずつ書き込み
データは6ノードに非同期・並列で書き込む
書き込みクォーラムは4/6、読み込みクォーラムは3/6
コミット=トランザクションが4つのノードに書き込まれた状態
1. ログレコードを受信してインメモリキューに追加
2. ホットログとACKでレコードを保持
3. レコードを整理し、ログのギャップを特定
4. ギャップを埋めるためにゴシッププロトコルを利用
5. ログレコードを新しいページバージョンに結合
6. 定期的にログと新しいページのバージョンをS3に保存
7. 定期的に古いバージョンをガベージコレクション
8.
Auroraは速い
PostgreSQLの2倍
複数のAZに最大15の昇格可能なリードレプリカ
REDOログベースの(物量)レプリケーションにより、レプリカの遅延が低い(通常10s未満)
フェイルオーバーの順序を設定可能なカスタムリーダーエンドポイント
通常のMySQLより速いのは、ストレージが共有されているから
ダブルライトバッファ？
Auroraはプライマリーインスタンスがストレージに書き込みに行く
4/6に書き込むまで待つ(トランザクションのコミット)
プライマリーが既に書き込んでいるストレージをリードレプリカに共有しているので、スループットが高い
MySQLのレプリカ
論理的な完全な変更
マスターと同じ書き込みワークロード
独立したストレージ
Auroraのレプリカ
物理的差分の変更
書き込みが発生しないレプリカ
共有ストレージ
自動的に追加/削除を行うAuto-scailingレプリカ
リージョンを跨いだリードレプリカ(Aurora Global Database)
MySQLからbinlogを利用したレプリケーション
リージョンを跨いだ例
ログとしてすべての変更が他のリージョンに送られる
ストレージがデータを他のリージョンに送ってくれる
非同期でレプリケーションが行われている
別のリージョンをプライマリーにすることが1分未満で可能
Aurora Parallel Query
Auroraストレージには数千のCPUが存在する
- クエリ処理をプッシュダウンして並列化
- 処理をデータの近くに移動することでネットワークトラフィックと待ち時間を削減
実現のためには多くのチャレンジ
Aurora lock management
MySQL lock manager
MySQLと同じロックセマンティクス
ロックチェーンへの同時アクセス
Aurora lock manager
個々のロックチェーン内の複数スキャナ
ロックフリーデッドロック検出
多くの同時セッションをサポートする、高い更新スループット
### 可用性
Instant crash recovery
最後のチェックポイント以降からログを適用する必要がある
チェックポイント間は通常5分
シングルスレッド、大量のアクセスが必要
Amazon Aurora
ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで再適用、分散、非同期
起動時に再適用なし
Cluster Cache Management
通常、データベースをバックアップしてキャッシュをウォームアップするにはしばらく時間がかかります。このフェールオーバーの例では、CCMがないと、DBの起動に32秒かかりましたが、パフォーマンスの90％を回復するには340秒でした
データベースのパフォーマンスを回復するにはキャッシュのウォームアップが必要
CCMが有効になっていると、データベースはウォームアップされたキャッシュを持っている？
Aurora Backtrack
Backtrackにより、バックアップからの復元を必要とせずにデータベースを特定の地点に戻すことが可能
破壊的動作ではないので、複数回Backtrack可能
Fast Database Cloning
既存のデータベースにポインタを設定する
Primary Storage←Clone Storage
15:00 【初級】Amazon EC2の進化の歴史から学ぶEC2入門 2019年版
「EC2を初学者が理解するのはちょっと大変だから、EC2の進化の歴史を通じてEC2のコアな機能について理解しよう」という趣旨のセッションでした。
本当にコアな機能に関しては2006年の時点で出来上がっていたのは驚きでした。
16:00 【初級】Amazon EC2 インスタンスタイプの選び方ガイド
EC2のインスタンスタイプの意味について、その用途と共に解説されました。
ざっくりまとめると以下の感じでした。
c5d.xlarge
c:インスタンスファミリー
5:インスタンス世代
d:(追加機能)
xlarge:インスタンスサイズ
クレジット:バースト性能を発揮できる量に制限がある
FTPサーバーなどの一瞬だけ高付加になるケースは、バースト可能インスタンスを選ぶ
選定のポイント
- Mを基準に重視するリソースから選択する
- 重視すべきリソースがわからないときは、まずはMタイプ
- 必要に応じてタイプを変更
17:00 【初級】AWSストレージサービス入門
AWSで提供されているブロックストレージ(EBS)、ファイルストレージ(EFS/FSx)、オブジェクトストレージ(S3)に関して、サービス概要と特徴的な機能、そして代表的なユースケースを紹介するセッションでした。
S3が静的ウェブサイトのホスティングやビッグデータのデータレイクとして活用できるのは目から鱗でした。
もっと勉強したいと思います。
18:00 【初級】AWSにおけるデータベースの選択指針
データベースは「データに対してどんな処理をしたいか」に合わせて選ぶ。
万能のデータベースは存在しない。
ということで、RDBMSの話から入り、RDBMSでカバーしきれないユースケースに関して、どのタイプのNoSQLデータベースを適用すればいいか、というセッションでした。
KVSとドキュメント指向DBまでは知ってたのですが、インメモリDB・グラフ指向DB・時系列DB・台帳DBに関しては全く知らなかったので超勉強になりました。
感想
濃いセッションだけでなく、初学者向けのセッションも豊富だったのでとても楽しめました。
Amazon Auroraの内部実装や、Amazonの文化についても知ることができて面白かったです。
一つ後悔があるとしたら、Day1・Day3の申し込みをしなかったことですね……。
来年は認定者資格引っさげて認定者ラウンジ利用したいです。
この記事が気に入ったらサポートをしてみませんか？