Faber Company 開発ブログ

ファベルカンパニーと読みます。

AWS Summit Japan 2024 参加レポート(2日目)

AWS Summit Japan 2024 #AWSSummit が2024年6月20日・21日に幕張メッセで開催中です。
aws.amazon.com

昨日に引き続き、2日目のセッションからFaber Company 開発運用チームから菅原・金子が気になった話題をピックアップして速報します!
※ 1日目の速報レポートは以下の記事をご覧ください fabercompany-dev.hatenablog.com

フォトスポットもおしゃれですね!

Amazon Aurora の技術とイノベーションDeep dive

公式概要

Amazon Aurora は、ストレージとコンピューティングを分離する革新的なアーキテクチャと、グローバル データベースや低レイテンシーのリードレプリカなどの高度な機能を備えており、リレーショナル データベースのあり方を再構築します。 Aurora は、オープンソースの MySQL および PostgreSQL との完全な互換性を備え、比類のないパフォーマンスと大規模な高可用性を提供する最新のデータベース サービスです。このセッションでは、Aurora I/O-Optimized、Aurora zero-ETL と Amazon Redshift の統合、Aurora Serverless v2 など、Aurora が提供する新機能について詳しく説明します。 pgvector 拡張機能の追加により、ベクター埋め込みの保存と生成 AI のベクター類似性検索のサポートがどのように可能になるかについても紹介します。

登壇者

塚本 真理 様

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 デジタルサービス技術本部 ISV/SaaSソリューション部 ソリューションアーキテクト

所感(金子)

開発運用チームでもAmazon Auroraにはお世話になっており、特にMySQLバージョンアップ時にはBlue/Green Deploymentを活用することでダウンタイム無しの移行を達成できました。この機能を実装してくださったAWSの皆様には感謝しかないです...!
今回の発表ではRedshiftとのZero-ETL機能やPostgreSQLにおけるOptimized Reads、生成AI関連のタスクで活用できそうなpgvectorなど、多くの機能の紹介がありました。それらは公式サイトでも紹介されているのでここでは割愛しますが、代わりにOptimized Readsの紹介の中で確認していた「DB負荷とALBのレスポンスタイムを比較する」という作業をピックアップします。
今までもスロークエリの調査や高負荷の要因をPerformance Insightsでチェックすることはありましたが、ユーザへの影響を測るためにALBのレスポンスタイム等のチャートと比べたことはありませんでした。技術調査の際にも、常にユーザ目線でのプロダクト価値を念頭に置くことの重要性を改めて感じました。

SaaS 開発とプラットフォームエンジニアリングの未来

公式概要

プラットフォームエンジニアリングは、ガートナーによる「2023 年の戦略的テクノロジーのトップ・トレンド」の一つに挙げられている技術分野であり、SaaS を開発する企業の間でも注目を浴びています。本セッションでは、SaaS ビジネスを展開する企業が、プラットフォームエンジニアリングのプラクティスをどのように開発組織に適用し、AWS のアーキテクチャに落とし込んでいくのか、ビジネスとアーキテクチャの両面から説明します。

登壇者

後藤 健汰 様

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 デジタルサービス技術本部 ISV/SaaSソリューション部 ソリューションアーキテクト

所感(金子)

「利益を維持しながら成長を維持する必要性が高まっている」というビジネス潮流の話から始まり、SaaS商材の戦略動向、それに対してなぜ開発生産性の維持/ 向上が求められるのか、という経営やビジネスのトピックも交えながらのセッションでした。本題であるプラットフォームエンジニアリングについての話では「プラットフォームを作る目的は『認知負荷』を下げること」「Platform as a Product」という重要な観点を紹介しつつ、具体的なゴールデンパスの設計方法やセルフサービス化を達成するために必要なマインド、そしてプラットフォームチームとしての成果をどう評価するか、という話まで、かなり広いスコープをわかりやすく解説していただきました。
当社の開発運用チームでも、複数プロダクトを提供する中で生まれる認知負荷や実装負荷を低減するための手法として、共通基盤を構築する必要性をちょうど考えているところです。今回の発表内容を受け、どのようにプラットフォームチームを立ち上げていくか、戦略を練りたいと思います。

※ プラットフォームチームの立ち上げ、推進にご興味がある方は採用サイトからカジュアル面談の申し込みもお待ちしております!

チームのつながりを Infrastructure as Code でデザインする

公式概要

ソフトウェア開発においてチーム間のつながりが不適切だと、俊敏性が減少し、開発コストが増大します。チーム内においても、異なるスキルやモチベーションを持つメンバー間の壁を取り払うにはメカニズムが必要です。Infrastructure as Code (IaC) はアプリケーション全体の状態と開発者の意図を明確化するため、チームの共通言語としてコラボレーションの基点になります。このセッションでは、日本のソフトウェア開発の現場におけるチームトポロジーや認知負荷について検討し、ビジネス価値を迅速に提供できるチームを作るために AWS Cloud Development Kit (CDK) による IaC を戦略的に活用する方法を学びます。

登壇者

高野 賢司 様

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジック製造グループ 中部ソリューション部 シニア ソリューション アーキテクト

所感(金子)

前半は「チーム構成」と「俊敏性や開発コスト」の関係性とその理想像、そして後半はチーム内外とのコミュニケーションの共通言語としてのIaCの活用方法についての紹介でした。印象深かったのは「インフラの自動化のためにIaCが必要だ」という目線ではなく、前述のセッションと同様に「チーム開発とはどうあるべきなのか、それがなぜビジネス価値や顧客体験に繋がるのか」という目線で語られていた点です。
また、最後の方ではチームトポロジーにおけるストリームアラインドチームとプラットフォームチームの在り方についても言及されており、CDK大好きかつ現在進行形で開発組織やチーム体制を考えている私にとって、とても価値のある発表でした。特に「職能でチームを分けることは、個人の成長機会や意欲を削いでしまう可能性がある」という点が重要だと感じたため、エンジニア自身のキャリアと組織目標のどちらにもいい結果をもたらすチームを作るため、日々精進していきたいと思います。

アーキテクチャ道場 2024!

公式概要

アーキテクチャ道場が今年も帰ってきました!優れたアーキテクチャを設計するためのプラクティスを AWS のソリューションアーキテクトと一緒に学びましょう。このセッションでは、ソリューションアーキテクトがお題に沿って実際に設計したアーキテクチャをレビューしながら、アーキテクチャを設計する際の着眼点、良いアーキテクチャが備えている性質、モデリングの手法やデザインパターンなどを深堀り解説します。

登壇者

内海 英一郎 様

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 チーフテクノロジスト

馬渕 俊介 様

アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ技術本部 サービスグループ トラベル・交通・物流ソリューション部 ソリューションアーキテクト

山﨑 翔太 様

アマゾン ウェブ サービス ジャパン合同会社 ストラテジックインダストリ技術本部 デジタルソリューション部 部長 / シニアソリューションアーキテクト

所感(金子)

前からYouTubeで見ていたアーキテクチャ道場を、とうとう生で観ることができました!!! 学びが多く、ただただ自分の未熟さを痛感する時間でした ...
1日目と今日のセッションであらかじめ「サーキットブレーカー」や「エクスポーネンシャルバックオフ」という単語を目にしていたため、2つ目のお題の答えには割と最初から正解に近づけていたかなという小さな自己肯定感を持ちつつも、山崎さんほど詳細かつ明快に説明するスキルはまだ私にはありません。これからも技術と真摯に向き合いつつ、言語化と実現力の2点を重点的に鍛え上げていきます。
そして、最後に内海さんがおっしゃっていた「現実世界には強くて柔軟な仕組みが多く、レジリエンスのヒントがたくさんあるので注意深く観察してみよう」というアイデアを日々実践し、技術に活かせそうなアイデアを貪欲に収集していきたいと思います!

小規模体制でも開発できた電動車椅子の自動運転サービス~ AWS IoT 、サーバレスのクラウド活用~

公式概要

すべての人の移動を楽しくスマートにする! 既に世界 25 か国以上で採用が進む日本の近距離モビリティ WHILL (ウィル)。その自動運転サービスは、 PoC の壁を乗り越え 2020 年に世界で初めて商用化まで実現しました。従来の"モノづくり"に捉われず、"サービスづくり"の視点で MaaS としての新たな移動の在り方を追求。 小規模チームながらどのように AWS のサーバーレスや IoT サービスを駆使し、実証やコンセプトで終わらず、人を乗せた近距離の自動運転サービスを社会実装できたのか。移動の自由を切り拓く WHILL社の取り組みをお届けします。

登壇者

福田 慧人 様

WHILL株式会社 CTO

所感(菅原)

ここまでの事例セッションは大手からのものが多かったのですが、創業12年の非上場企業の事例ということでセレクトしました。

羽田・成田空港で自動運転を行っている電動車椅子でおなじみですが、その WHILL がエンジニア1~2人という超小規模なチームで社会実装を実現したことに驚きです。 このスピード感・規模感は徹底したサーバレス構成で実現されており、最初から海外展開を狙った柔軟性の高いシステム構成を事業展開上のアドバンテージとしてフル活用できているイメージを受けました。

ソフトウェア、ハードウェア、サービスが近づくことでより高い付加価値を提供する、まさにテックベンチャーの戦い方。その片鱗を垣間見ることができました。

富士通が AWS と共に取り組む『攻めのモダナイゼーション』

公式概要

富⼠通と AWS が、共同で提供するクラウドソリューションによる『攻めのモダナイゼーション』を紹介します。今企業では、その⽣命線であるメインフレームや UNIX で稼働中の基幹情報システムを安全・確実に最適な DX 基盤に移⾏することにより、データ利活⽤・事業継続性確保・変化対応⼒強化を加速することが求められています。このセッションでは、富⼠通の豊富な IT 経験と AWS の先進的なクラウド技術が融合することによって、成功したモダナイゼーションの事例を中心に解説します。

登壇者

伊井 哲也 様

富士通株式会社 モダナイゼーションナレッジセンター長 SVP

所感(菅原)

Faber Company ではオンプレミス環境・メインフレームは扱っていませんが、依然としてソースコードのモダナイゼーションは関心事のひとつです。

セッション内で、まず「モダナイゼーションの目標は事業変革・経営改革」とはっきり宣言なされており、はっとさせられました。 なんのためにモダナイゼーションをやるのか?は常に説明する必要がありますが、エンジニアだけの組織では抜け落ちてしまいがちです。 モダナイゼーション、リファクタリングの目標はベトナム支社のエンジニアからも説明できるくらいチームで咀嚼しておく必要を感じました。

セッションで扱われていたアプリケーションは基幹情報システムなので、当社が提供するようなウェブサービスに比べて品質の要件が厳しいです。 コードベースの移行にあたって、10% 程度移行してみてその後の継続可否を判断することや、テストプランの策定・運用方法は、ミエルカの品質向上においても活用できそうです。

総括

1日目レポートでも触れた通り、イベント全体を通して生成AIに対して高い期待が寄せられていました。2日目も同様、業種を問わず、手持ちのデータをどのように活かすかがさまざまな事例から提案されていました。

もちろんマーケティング業界も例外ではありません。お客様に価値ある意思決定をしていただくために、「よりよいデータを集め、よりよく活用すること」を突き詰めていきたいです。

もうひとつ感じたのがセキュリティ意識の高まりです。データを活用するにはセキュリティ対策は切っても切り離せませんし、最近の世界情勢も相まってサイバーセキュリティに対する需要も高まっています。

当社のビジネス成長の成功には、堅牢なセキュリティとそれを実現するための継続的な開発組織の成長が不可欠です。クラウドの環境を活かしつつ、これからも安心して使っていただけるサービス作りに努めていきます。