はじめに
こんにちは！
NTTデータ ペイメント事業本部 カード＆ペイメント事業部デジタルペイメント開発室の、チーム tonttu です！
私達のチームは決済中継サービスの非機能改善や技術検証を担当しています。
3/1(金)にGoogle Cloud Modern App Summit Tokyo'24が開催され、チームメンバーの松井と石田が参加してきました。
本当に面白いセッションが数多くあったので、いくつかピックアップして簡単にご紹介します。
※現在アーカイブも公開されていますので、ぜひ気になった方は下記リンクからご覧ください！
Platform Engineering
Platform Engineeringに関しては複数のセッションで取り上げられており、その注目度の高さを感じました。
その中で、Google Cloudの関本さんによる「これからはじめるPlatform Enginnering」を紹介します。
そもそもPlatform Engineeringとその目的は以下のようです。
プラットフォーム エンジニアリングとは、組織において有用な抽象化を行い、セルフサービス インフラストラクチャを構築するアプローチです。散乱したツールをまとめ、デベロッパーの生産性を高める効果があります。プラットフォーム エンジニアリングの狙いは、デベロッパーが体験する日常的な困難を解消して、行きすぎた責任共有モデルが引き起こす学習の手間を抑制することです。
例えば、アプリエンジニアがモダンなアプリ開発業務にアサインされた時であっても、ビルド、デプロイ、インフラリソースの作成、セキュリティなど、幅広い専門分野の知識が必要になっていますよね。
そのような背景によって、開発者の認知負荷の増大が大きな課題をなっており、Platform Engineeringが注目されています。
私も様々な分野のことを考えなければいけないときに、良く理解力や集中力が急に無くなってしまう時があるのですが、これが認知負荷というものか、と思いました。
Platform Engineeringによる恩恵
- 認知負荷を軽減、燃え尽き症候群のリスク軽減
- 低コストで市場投入までの時間短縮
- 組織に合わせたガードレールを取り込み、安全性を向上
アプリ開発者が活き活きと開発に注力出来る上、安全にかつ素早く市場に投入出来ることからエンドユーザーの方にまでメリットがある、と考えることが出来ますね。
どのようなPlatformを目指す？→ゴールデンパスを参考にする
ゴールデンパスとは一言でいうと下記のようです。
迅速なプロジェクト開発に役立つコードと機能のテンプレート
詳細はGoogle Cloudさんのブログにも説明があるのでこちらも合わせてご参考に
例えば、「プロビジョニングの自動化」に関して、私のプロジェクトでは、CI/CDパイプラインのテンプレート、terraform module、helmテンプレートなどがあり、各アプリチームが機能開発を行う際にスムーズにデプロイが出来る環境が整えられており、プラットフォーム利用者の認知負荷の軽減に繋がっています。
自プロジェクトの課題
徐々にPlatform Enginneringの考え方を取り込んでいますが、逆に抽象度を高くしすぎるとブラックボックス化してしまい、アプリ開発チームからの問い合わせも増えてしまうことです。
認知負荷を下げることも大事ですが、組織として自律的に動けるようになるためには、アプリ開発チームからの依頼があった際にインフラチームのメンバーが一緒になって作業をしてみるなど、組織としての技術力の底上げも大事だと思います。そのためには組織に合わせて抽象度のバランスを調整していくことも必要かなと感じました。
データベースを選ぶ時の勘所
Google Cloudの大久保さんによる「大解剖アプリケーションに合わせてデータベースを選ぶときの勘所」のセッションについてです。
Google Cloudを利用している・これから利用する予定のある方はぜひ一度ご覧になることをおすすめします！
Google Cloudでは様々なDBが用意されていますが、ユースケースに応じてどのように選定すべきか迷ってしまう方は多くいらっしゃるのではないでしょうか？
その際に本セッションで説明されている比較表を用いながら考えると良いと思います。
また、Google Cloudで提供されているDBについての理解も深まります。（私も読み込んでます。）
メルペイ開発当初に戻って Spanner のテーブル設計をやり直せるなら
松井はこのセッションを見つけた瞬間にイベントへの登録を行いました。
チームtonttuでは半年ほど前からCloud Spannerの導入検証やテーブル設計を行っており、Spanner登場初期から使用されているメルペイさんの知見は絶対に役立つはずだと考えました。そして、実際にセッションを聴講して「登録してよかった」と実感しました。
Spannerは時系列データの取り扱いが難しく、どのような扱い方をするべきか悩んでいたのですが、メルペイさんでの扱い方を知ることができたり、検討案から抜けていたcommitタイムスタンプについて知ることができました。
commitタイムスタンプとは、TIMESTAMP型のカラムにオプションを付与することで、トランザクションがデータベースに commitされた時刻を書き込むものです。このオプションが付与されたカラムをWHERE句の条件にすると、Spannerが内部でI/Oの最適化を行ってくれるため、時系列データの読み取りのためにアンチパターンであるTIMESTAMP型のカラムにINDEXを貼ったり、shardIDを使用した論理シャーディングをする必要がなくなります。
ただし、セッション内で「直近のデータに対して」という言葉があったように、このcommitタイムスタンプは直近のデータへの検索に有用です。自チームで過去のある時点を指定してクエリを叩く検証をすると期待した性能は出ませんでした。
そのため、セッション内でも仰っていたように、直近1日のデータに対してBatch処理をするというようなユースケースでは優位な選択肢になるのではと思います。
まとめ
今回は Modern App Summit Tokyo '24 の参加レポートを書いてみました。
こういったイベントは知らなかった機能やネットの記事には落ちていない他社事例を知ることができたりと、非常に有意義なものであると再認識しました。
引き続き様々なイベントに参加し、学びを自組織に活かしていきたいと思います！
おまけ
夜には懇親会がありました！
種類豊富なビールを片手に、他社でのGoogle Cloud活用について聞いたり、弊社のGoogle Cloudコミュニティについて話したりと会社の垣根をこえて交流をしました。
普段の業務では出会わないエンジニアと交流できる点もこういったイベントの魅力です。
