db tech showcase 2024 Tokyo参加レポート
2024/07/11 - 12にかけて開催されたdb tech showcase 2024 Tokyoに参加したので、感想と参加したセッションの内容を簡単にまとめたいと思います！
参加してから1ヶ月近く寝かせてしまいました💦
一旦自分用のメモとして、殴り書きで残しておきます。
db tech showcaseとは
株式会社インサイトテクノロジーが主催する、「データベース技術のオモテもウラも語り尽くす」をコンセプトに、世界中から様々なデータベースのトップエンジニアを招聘して開催する日本で最大規模のデータベース技術カンファレンスです。
参加理由
データベース技術の最新情報や、知らないデータベースの情報を仕入れるためです。
私自身Oracleをメインにデータベースを業務として扱っているため、日本国内で大規模なデータベース技術カンファレンスは他にないと思い参加しています。
感想
楽しかったです。
私は2日目だけ参加させて頂きましたが、久しぶりに大規模なカンファレンスに参加したため、データベースという親和性の高いイベントだからこそ勉強になることも多かったし楽しめたと思います。
また、時代背景もあり専門分野である"Oracle"のセッションは少ない印象でしたが、カンファレンスだからこそ業務では扱わない技術であったり他社さんの事例などが聞けるので、とても勉強になりました。
ただ、反省点（反省することでもないと思いますが）としては、会社に持ち帰れる情報があまりなかったことです。
今回参加したセッションが自分の興味に全振りしていたので、会社としては親和性がなく、展開できるような内容ではなかったかもしれません。
少しはそういった部分も心がけようと思います...笑
あと、展示ブース会場には、見知った顔の方がちらほらいたので、そういった方々と久しぶりにお話する機会になったのもとても良かったです！
セッション
簡単にですが、参加したセッションの感想を書いていこうと思います。
（本当に簡単にです）
B11: AlloyDB 徹底解剖 -高可用性、性能を生み出すアーキテクチャと運用負担を軽減するためのポイントを学ぶ-
お恥ずかしながらAlloyDBはじめて聞きました。
内容は、AlloyDBのパフォーマンス、アーキテクトのお話が中心でした。
AlloyDBは、Googleの経験を詰め込まれたPostgreSQL互換の分析クエリなどを得意とするDBという印象を受けました。
技術的な部分もさることながら、従来のPostgreSQLより半分のリソースでパフォーマンス向上が見込めるという点が、パフォーマンスにもコストにもどう響くのかがとても気になりました。
Googleの技術を触らずに来てしまったので、これを機に少し調べてみようかと思いました。
B12: 実践導入！キャッシュレイヤによるOracleコスト削減
コスト削減はどの会社も急務な課題ですよね。
内容としては、従来のパフォーマンスの改善方法、キャッシュを活用すべき理由、効果的なワークロードのお話でした。
私自身、元同僚がAmazon ElastiCache for Redisを活用してパフォーマンスを改善しているのを目の前で見ていたので、キャッシュレイヤーの重要性はわかっていたつもりです。
ですが、どういった部分に使うべきなのかがいまいちわかっていませんでしたが、効果的なキャッシュワークロードのお話を聞けたのは勉強になりました。
- 読み取り/書き込み率が高い（70%以上）
- 複数のリードレプリカがあるデータベース
- 読み取りが繰り返されるワークロード
- 高いデータベースのRPS(request DB per sec)コスト
B13: 使い慣れたSQLに潜む実装依存
内容としては、複数のDBMSで同じSQLを実行した時の実行結果を比較した話です。
正直、勉強になった！ということ、これ全部検証したのか...という感想です。笑
私自身、Oracle,MySQL,PostgreSQLを同時に触ることはありましたが、幸いあまり躓くことはありませんでしたが、SQLをゴリゴリ書く人にとっては「あるある」な内容だったかもしれません。
PC14: CyberAgent ピグパーティにおけるMongoDB Community バージョンからAtlasへの移行事例
内容は、最近よく耳にはするMongDBに関する紹介とCyberAgentさんの移行事例紹介です。
多種多様なdeveloper platformが準備されているMongoDB。
移行に関するツール類も取り揃えており、さらに有償のコンサルサービスを活用することで手厚いサポートが得られる、というお話でした。
NoSQLはまだあまり触っていないので、今後触れて行きたいです。
C15: 2024年データベースの選択は？ 最新RDSの性能比較をしてみる
HammmerDBを使用した、Oracle, MySQL, PostgreSQL, SQL Serverのベンチマークテストの内容です。
結果は、Oracleが一番早かったものの、その他は適切なパフォーマンスチューニングを行うことで同じくらいの性能が出ることがわかりました。
分析観点を予め絞っておくことで、どこにボトルネックがあるのか、という観点でも勉強になりました。
C16: Amazon Aurora/Amazon RDS でのコストの最適化
コストの最適化を行う上で、RDSとAuroraのコスト構造を理解することが大事、という話でした。
コスト削減方法も特別なことはなく、コスト構造を理解した上で、不要なインスタンスは削除または停止、最新世代のインスタンスタイプに変更しよう
コストエクスプローラーなどを活用してモニタリングしながら、地道に必要なことをするのが大事、ということがわかりました。
D17: 爆速成長中のFindyがぶつかった課題と解決に向けた実践手法
性能改善の方法についての話でした。
内容としては、、ケールアップ、リアーキテクチャ、SQLでチューニング、アプリケーションでチューニングをやられているとのこと。
中でも内容として響いたのが、リアーキテクチャやアプリケーションでチューニングの箇所において、DBREもアプリを理解してSWE(ソフトウェアエンジニア)もSQLを理解して、それぞれの強いところを活かしてタッグを組むのが大事、という箇所です。
頭ではわかっているものの、SQLだけで解決しようとしたりする癖があるので、連携しながら最適案を見つけるようにしないといけない、と思いました。
B20: 【SBペイメントサービス】TiDBで私達は幸せになれたのか? 〜止められない決済システムにTiDB Cloudを導入した理由〜
TiDBに移行した理由と移行した結果、その後のトラブル解消についての話でした。
内容の中で、MySQL互換ということもあり既存のコードを変更なしでTiDBに移行できたことはすごいのですが、レスポンスタイムとしてはTiDBの方が劣る部分があるため、やっぱり向き不向きはあるんだな、という印象でした。
結果的に、移行後に一度トラブルはあったが、ドライバーの問題ですぐ解消したということなので、データベースとしてはやはり優秀なものだと思いました。
最後に
以上、拙い文章でまとめさせて頂きましたが、個人の感想なので実際の内容と異なる部分は多々あるかと思いますが、温かい目で流し見してくれるとありがたいです。
Discussion