Feedforce Developer Blog

フィードフォース開発者ブログ

AWS Summit Tokyo 2018 に行ってきたよ

f:id:m-maeda:20180606123136p:plain

こんにちは、今回が初ブログ投稿になる今年の1月にフィードフォースにバックエンドエンジニアとしてジョインした id:m-maeda です!
先日 AWS Summit Tokyo 2018 に行ってきましたので、その感想を書こうと思います。

今年の AWS Summit Tokyo は、5/30、5/31、6/1 の3日間でしたが、初日の 5/30 に行ってきました。
いろいろなセッションがありましたが、当日は以下のスケージュールで行動しました。

10:00 ~ 基調公演

12:00 ~ エンジニアの為の Amazon Pay ベストプラクティス

13:00 ~ 展示ブース巡り & AWS認定者ラウンジで休憩

15:00 ~ Amazon Aurora Under the Hood

16:00 ~ SIOS Coatiをサーバーレスアーキテクチャーで全部書き直してみた!

17:00 ~ 再び 展示ブース巡り & AWS認定者ラウンジで休憩

18:30 ~ 帰宅

基調講演を除くと、参加したセッションは 3 つでした。
いつも欲張ってたくさんセッションを見ようとしてしまいますが、今回は参加するセッションをつめつめにしなかったおかげでゆっくり見れてよかったです。
あとで動画で見れるセッションもありますしね。

会場に着いてまず最初に驚いたのは人の多さ!!
品川プリンスホテルに入ってから受付完了まで20分ぐらいかかったんじゃないかなぁと思います。
一緒に行った社員に聞くと、昨年の AWS Summit よりも人がかなり増えていると感じたと聞きました。
昨年よりもますます AWS に注目が集まっていてるからだと思います。

基調公演

基調公演の会場は「飛天の間」という会場で行われたのですが、人が多すぎるからかモニターを設置しているサテライト会場から見ることになりました。
本会場ではたまに拍手が起こりますが、サテライト会場では拍手のタイミングでもシーン。。なのでちょっと寂しかったです(笑)。

まずは AWS 長崎社長。 演説するのが上手でした。
2017年度比の売上成長率が 49% だったそう。
これだけ大きな会社が 49% 成長、って半端ないですね。

そのあとは KDDI株式会社、ソニー銀行株式会社、SOMPOホールディングス株式会社、株式会社デンソー、株式会社ABEJA の代表者達がそれぞれ登壇しました。
去年に比べて社会インフラ系の方達の登壇が多いように思いました。
携帯電話会社や銀行や損保会社で AWS が使われている、という事例があると、「インフラ最大手の企業が導入してるんだからうちも」と他の会社もなりますよね。
国内の閉鎖的だった大手企業や中小企業も、今後ますます導入していく企業が増えそうです。
AWS さんの狙いはその辺りかな、と感じました。

そして大きな発表が2つありました。

まずは EFS 東京リージョン。
私が所属しているフィードフォースのソーシャルPLUSチームでは、複数の EC2 のディスクを共有して使うという需要はあまり無さそうですが、今後使いどころがあれば使っていきたいです。

そして AWS Loft。
特徴は「AWSのソリューション・アーキテクト(SA)をはじめとする技術者陣が常駐している」「セミナーや勉強会が開催される」「無料で利用できるコ・ワーキングスペース」。
個人的にこれはめっちゃいい!と思いました。
私自身、コワーキングスペースが好きでたまに行くのですが、サンフランシスコとニューヨークにすでにある AWS Loft の画像を見てみるとおしゃれな空間っぽい雰囲気なのでもうすでにテンションが上がっています。
オープンしたらすぐに行ってみたいですが、無料で利用できるみたいなので人が多すぎて入りきらないんじゃないか、と今からちょっと心配しています。

エンジニアの為の Amazon Pay ベストプラクティス

スピーカー : Jonathan Froeming 氏、山崎 晃 氏、伊藤 樹法 氏(アマゾンジャパン合同会社 Solution Architect, Amazon Pay)

Amazon Pay をどうやって実装していくか、というのを AWS の中の人たち(Solution Architect Jonathan Froeming 氏、Solution Architect 山崎 晃 氏)が演じるという内容でした。
テーマは「いかに離脱率を下げて決済までしてもらえるか」。
Jonathan Froeming さんが UX に無頓着なエンジニア、山崎さんが 実装をお願いした上司、という配役で、すごくわかりやすくてお互いの掛け合いもすごい面白くて途中何度か笑いが起こっていました。

「ボタンの位置や配色でユーザーの購入率が変わる」「ユーザーの個人情報入力フォームを無くす」など、非常に具体的な内容ですぐに実践できる内容だと思いました。
私自身、ECサイトで買い物をした時に、個人情報のフォームを入力するのに面倒だと思って何度か購入を諦めた経験を思い出しました。
正直 Amazon Pay のことについて全然無知だったのですが、めっちゃ便利じゃん!と思ったので、開発者目線というよりもむしろエンドユーザー目線ですが、どんどん Amazon Pay が ECサイトに実装されていってほしいと思いました。

Amazon Aurora Under the Hood

スピーカー : 江川 大地 氏(アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト)

「Under the Hood」とは、念入りに調べる、という意味だそうです。
セキュリティや可用性、冗長性についてなどの視点で Amazon Aurora の内部アーキテクチャなどを詳しく説明してくれました。

Aurora の機能の中でも他の RDS と大きく違う点がストレージです。
Aurora は 10GB から 64TB まで自動でストレージを拡張してくれる、という機能があります。
普通の RDS では容量が MAX になってしまうと RDS インスタンスに接続できなくなったりなど、非常に重大なインシデントが発生します。
容量が MAX になる前にストレージを拡張することになりますが、再起動が必要なのでどうしてもダウンタイムが発生します。
それらの点をすべて考慮しなくてもよい Aurora 、素晴らしいですね!

また、Aurora は非常に高い可用性を持っています。
その高い可用性を実現するために以下の3つのポイントを採用しているとのこと。

  • 3つの AZ にそれぞれ 6つのデータをコピー
  • クォーラムシステムを採用
  • 継続的に S3 へデータの増分をバックアップ

一般的なデータベースの可用性はマスターDBをスタンバイDBにレプリケーションしておいて、万一の時はスタンバイDBをマスターDBに昇格させる、という方式で担保します。
ただし、同期レプリケーションの場合はレイテンシが遅延する問題、非同期レプリケーションの場合はデータロストの問題が発生する可能性があります。
Aurora では各クラスターはログレコードとデータページの2つのデータで構成されており、非同期処理でログレコードへ書き込み処理を、データブロックは後ほど必要な時に書き込む処理になっているそうです。

また、それぞれのストレージの書き込み・読み込み処理にクォーラムシステムというのを採用しているということでした。
恥ずかしながらクォーラムって何だろう、とその場では分からなかったので持ち帰って調べました。

以下、クォーラムシステムの解釈です。
※ 間違いがありましたらご指摘ください 🙏

Aurora では各 AZ にクォーラム(クラスター)が2つずつで AZ 3つをまたぐので計6個配置されます。
f:id:m-maeda:20180606125321p:plain

データの書き込みは6つのクォーラムのうち、無作為な4つのクォーラムに対して成功すると書き込み成功と見なされます。 f:id:m-maeda:20180606125403p:plain

データの読み込みは無作為な3つのクォーラムに対して実行し、日付が最新のデータを正とします。 f:id:m-maeda:20180606125521p:plain

6つのクォーラムに対して4つ書き込み、3つ読み込むと、必ず1つ以上は書き込みと読み込みが重複するクォーラムが存在することになるのでデータの一貫性が保たれる、というわけです。
(これが4/6クォーラム。3つのクォーラムに対して2つ書き込みは2/3クォーラム、7つのクォーラムに対して4つ書き込みは4/7クォーラム、と表します) f:id:m-maeda:20180606125623p:plain

可用性を担保しつつ、データの一貫性も保証するクォーラムシステム、すばらしいですね。
結構単純なロジックですが、勉強になりました。
ちなみにDynamoDB も同じくクォーラムシステムを採用しています。
クォーラムについて調査したことなどは以下の記事を参考にさせて頂きました。

また、それぞれのクォーラムで異常が検知されると同じクォーラムグループを作成し、異常のあるクォーラムを正常なクォーラムに置き換えて新しいクォーラルグループとすることで健全な状態を保っているそうです。
長期間の AZ 障害が発生した時などは、正常なクォーラムを残して3/4クォーラムにすることもあるそうです。
それぞれのクォーラムはログレコードとデータページの2つのデータで構成されていますが、6つのうち3つはログレコードのみで全体の容量を抑えているそうです。

Aurora は機能がすごくて便利だなぁぐらいで中身のことについては無知だったのですが、「Amazon Aurora Under the Hood」に参加して色々知ることができました。
ただ、このセッションは内容が多くて深く、すべて追いきれませんでしたのでところどころ解釈を誤っている部分があるかもしれません。
もし動画がアップロードされましたらもう一度見たいと思います。

SIOS Coatiをサーバーレスアーキテクチャーで全部書き直してみた!

スピーカー : 栗原 傑享 氏(SIOS Technolgy Corp. Business Development Director, Member of Board)

Coati という Web サービスを知らなかったのですが、サーバーを監視して、service を再起動したりするそうです。
古いシステムでは以下のようなネガティブ要素があったので、今回サーバーレス化に踏み切った、とのことでした。

  • お客さんのEC2を触るのはリスクが高い
  • インスタンスを立てるのはコストがかかる
  • ssh キーを預かるのはリスクがある
  • Web で全部完結させたい
AWS での Saas 実現テクニック

AssumeRole を使う、です。
監視系のサービスでは当たり前っぽいですね。
これを使ってクロスアカウントでお客さんの環境のサーバーを触ったりするそうです。

AWS Lambda の問題点
  • たまに発火しないことがある

これについては Step functions でリトライを担保するようにしているようです。

サーバーレスとは何か

サーバーレスとは「パーツの再利用」である

なるほどなぁと思いました。
サーバーレスのアプリはそれぞれが小さくまとまって完結しているので、サーバーレスで使うコードは再利用性が高いなぁと思っていました。
個人的にサーバーレスのアプリは少し前から興味があって、AWS SAM を利用したアプリなどを作っていましたが、今後もさらにもっと勉強していきたいなと思いました。

展示ブース巡り & AWS認定者ラウンジ

いつもお世話になっている GitHub さん。
ステッカーをたくさん頂きました。
GitHub Japan Satellite Tokyo 2018 がもうすぐ開催される、ということでパンフレットを頂きました。 f:id:m-maeda:20180606142753j:plain

Datadog さんのブースにも行ってきました。
可視化ツールの進化がすごかったです。 f:id:m-maeda:20180606142802j:plain

AWS Snowball !!
初めて見ました。
結構大きかったです。
重さは米俵2俵分ぐらいはありそうでした。
データが絶対に外に漏れないようにセキュリティは万全にしてある、と説明員の方がおっしゃっていました。 f:id:m-maeda:20180606143018p:plain

Tシャツや鯖缶などを GET しました。 f:id:m-maeda:20180606143019j:plain

認定者ラウンジでステッカーをもらいました。
去年はバッジだったらしいです。
f:id:m-maeda:20180606142806j:plain

感想まとめ

とにかく人が多くて並ぶ時間も多くて疲れました。
ただ、疲れた時に認定資格者用ラウンジでゆっくり休憩できるのはありがたかったです。
「Amazon Aurora Under the Hood」の内容が多くて深くて理解できなかった部分があるのでもう一回聞かないとと思っています。
無料のお弁当美味しかったです、ありがとうございました。
来年も来れるといいな、と思っています。