この記事はSpeee Advent Calendar 2019の15日目です。遅刻ですね 🙇♀️
こんにちは、開発基盤ユニットの田頭です。 好きなAWSのサービスは AWS CodeBuild と Amazon Aurora です。いつかどこかで Amazon Aurora Serverless を使ってみたいと企んでいますが、未だに機会に恵まれません。
12月1日〜12月7日にかけて、 AWS re:Invent 2019 にはじめて参加してきました。新サービス発表などについては既に公式より発表があるのでそちらに譲りまして、参加してみて個人的に強い興味を持ったセッションをいくつか紹介でもしようかなと思います。
公式による新機能一覧のスライドはこちら(200ページくらいあります) 👉 https://www.slideshare.net/AmazonWebServicesJapan/20191206-aws-black-belt-online-seminar-aws-reinvent-202177403?ref=https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-reinvent-2019update-2019/
また、セッションの動画は YouTube の AWS Events チャンネルにて配信中ですので、こちらも要チェキです。
Amazon Aurora Multi-Master: Scaling out database write performance
2018/08/08に GA となったAurora MySQL の Multi-Master 機能を使って MySQL を無限にスケールさせる話です。個人的には一番おもしろかったセッションでした。
Aurora のよくあるユースケースとしては、 Write インスタンスを1台、Read インスタンスを複数台用意して、Read を分散させてスケールさせる構成が一般的ですが、Multi-Master を使えば Write インスタンスを複数台用意することができるので、Read だけではなく Write もスケールさせることが可能です。
一方で、異なる Write インスタンスへの書き込みが原因でデッドロックが発生する可能性が出てくるので、それを回避するためにテーブル単位で参照する Writer を切り替えるなどの対策の紹介があり、現実のユースケースにおける向き不向きが想像しやすくて良いセッションだなと思いました。
また、Multi-Master だとフェイルオーバーが高速になるとのことで、なんと50秒→10秒程度まで縮まるとの紹介もありました。すごい！
サービスの規模や性質次第だとは思いますが、使い所を見極めて投入すればかなりの成果を発揮するのではないか、ととてもワクワクするセッションでした。
なお、現時点で提供されている Aurora MySQL の Multi-Master は、 MySQL 5.6 との互換のみとなっています。
How Amazon.com migrated its applications from Oracle to AWS databases
Amazon.com が社内から Oracle Database を全廃したニュースが少し前に話題になりましたが、その詳細が解説されました。
Amazon が抱えるデータ量の規模に圧倒されたり、
汎用的に Oracle にデータを蓄積するのではなく、それぞれのユースケースに合わせて適切な AWS のデータストアに載せ替えていきたい、という誰もが頷きたくなるようなマイグレーションの動機の話があったり、
Oracle の利用状況を可視化する為に KPI を設定した話(なかなかパンチが効いていますね！)があったり、DMS を使った Aurora PostgreSQL や DynamoDB へのオンラインマイグレーションの構成事例の紹介などがありました。
結果的には50%近いコスト削減や、2倍以上のパフォーマンス改善、管理コストの削減に成功したとのことで、それぞれの用途に最適化されたサービスを選択していくことの大事さが痛切に伝わってきました。
MySQL options on AWS: Self-managed, managed, and serverless
AWS の MySQL を用いる際の選択肢についてのセッションのはずが、8割がた Aurora の話をしていた点や、EC2 上に自分で MySQL を配備して運用しているユーザが10数名ほど手を挙げていた点が印象に残ったセッションでした。
RDS についての新たな知見はそんなに無いかなーと思いつつ聴いていたのですが、
- 2019年5月ごろから RDS の請求書に秒単位での稼働時間が表示されるようになった
- MariaDB がパフォーマンスインサイトに対応した
- Aurora のリージョンまたぎのレプリケーションはおよそ1秒以内のラグ
- MySQL で password-validation プラグインをインストールする事が出来るようになったらしい
- RDS Proxy を使うとフェイルオーバーが 66% くらい速くなる
などの細かい知らなかった事がもりもりと出てきました。これぞセッションに参加する醍醐味だな、と思います。
Architecting security & governance across your landing zone
Speee でも絶賛実践中のマルチアカウント構成を、どのようにセキュアかつ自動化された状態で構成するか、といった旨のセッションです。
マルチアカウント構成を実施していると、主に以下のような問題と直面することになります。
- GuardDuty や CloudTrail などの監査ログ系の設定を全アカウントに適用したい
- アカウントごとにアクセスできないサービスを定めて、うまく適用したい
- これらを手動で設定していたらマルチアカウントがうまく回らない
これらのマルチアカウント特有の悩みを解決する為に、AWS Organizations 及び AWS Control Tower の利用が案内されていました。
Organization Unit の分け方の推奨例の紹介もあり、これを参考にしながら Speee の組織構造に当てはめていくと、この OU は削っても良さそうだな、などと想像することが出来、とても為になる発表でした。
ぜひとも Control Tower を取り入れていきたいと思い、帰国後に試していたのですが、 現時点では Control Tower は既存の Organization が存在している場合は利用出来ないようで(って既に re:Inforce 2019のレポートに書いてありましたね 😇)、今後のアップデートに期待したいところです！
まとめ
今回ははじめての re:Invent というのもあり、完全にセッションオンリーで参加してしまいましたが、それでも狙いのセッションを探すのが大変なほどに膨大な数のセッションが存在しており、とにかくイベントの規模感に圧倒されました。 また、 Workshop や Chalk Talk などにも参加してみなかったのは勿体なかったかもしれないなーと思う部分があります。しかし、一方で人によって千差万別の体験があるのも re:Invent の醍醐味と言えるのではないでしょうか。
全体的を通して現実のユースケースを交えた話が多かった印象があり、カタログスペックの向こう側の知見が多かったのはとても良い学びになりました。 なお、re:Invent へは業務として参加しており、イベントチケット代、交通費、宿泊費などは会社に出していただきました！ 感謝の念でいっぱいです！
最後に、Speee では開発基盤や SRE におけるエンジニアを募集しています！ 興味を持たれた方がいましたら、ぜひともお気軽にお声掛けください！
こまかい旅のTIPS
- 私はわりと現金を使うタイプで、帰国後に大量の硬貨が財布に残ってしまって、とはいえ窓口で両替するのも面倒だし……と頭を抱えていたのですが、ポケットチェンジというサービスを使って、端末に小銭を流し込むだけで日本円に変換しつつ手持ちの Suica に流し込むことで解決しました。海外旅行の帰りに小銭を持て余した時におすすめです。
- 会場となるホテル間の移動には、ぜひとも AWS が用意してくれている無料のシャトルバスを積極的に利用しましょう。軽率な気持ちで徒歩で5会場を移動したところ、1日で30000歩以上歩くことになり、足が大変なことになりました。
