活動履歴データのレプリケーションについて

こんにちわ。 Baseconnectバックエンドエンジニアの河野です。

今回は弊社営業支援ツール「Musubu」で提供している機能の一つに活動履歴という、営業案件に対してユーザーが行なったアプローチをログとして残すものがありますが、その活動履歴について新しいDBに対して非同期でレプリケーションを行うパイプラインの整備&技術検証などを行なったのでシェアできればと思っております。

プロジェクト背景

この活動履歴という概念がサービスの要件として登場したのは創業初期の段階で、詳しい事情は知らないのですが現状DynamoDBをマスターDBとして利用しています。

NoSQLでスキーマレスなデータ構造に強く、設定したプライマリ&セカンダリのインデックスで高速検索にはもってこいの優れたマネージドDBではあるものの、欠点として1度の検索に使える軸が多くても2つまでという点があります。

今後の活動履歴を活用した営業案件の検索などのサービス構想上、3つ以上の検索軸の発生 & Elasticsearchに保存されている営業案件と組み合わせた検索の発生という点を鑑みて、

活動履歴のマスターDBとしてはDynamoDBを残したまま検索用のDBとしてElasticsearchにレプリケートし、 活動履歴を用いて営業案件の検索を行なったり案件を横断した活動履歴の集計などを行えるような土台を整えたという流れになります。

進め方

設計

パイプライン設計

要件
  • 非同期遅延を最小化
    データパイプライン使用によって発生する非同期遅延がどの程度か実装しながら検証し、企画と相談。
  • DynamoDBのaction logテーブルのパーティションキーごとにストリーミング処理の順序を担保
    任意の活動履歴への更新のレプリケートはorder criticalなので。
  • 活動履歴変更イベントをサブスクライブするコンシューマーが増える可能性を考慮

前提

dynamoDB streamのシャード(パーティション)ごとの直列処理

争点

①dynamodbのキャプチャリングデータをどこに流すか
  1. dynamoDB stream
  2. kinesis data stream

判断材料

■ s3, es, redshiftへのコードレスなデータレプリケーションを使用する機会は今後登場するか?(kinesis firehose)

結論: 今のところ必要ないので、必要になり次第ダウンストリームにkinesisを配置。リアルタイム分析の機会が今後登場するか?(kinesis analytics)

結論: 今のところ必要ないので、必要になり次第ダウンストリームにkinesisを配置

■ シャード数を柔軟にコントロールする意味があるか?

  • 現在はシャードごとにParallizationFactorを調整することで、シャードごとのlambda並列度を1~10まで設定可能
  • DynamoDBは10GBごとに、もしくはWCUが1000, RCUが3000を超えるたびにシャードが1つ増加する
  • kinesisは自由にシャード数の調整が可能

結論: ParallizationFactorの調整である程度のスケールは可能なので、一旦シャード数の管理がマネージドで実装しやすいdynamoDB streamを採用し、 負荷テストなどの検証の結果シャード数が少なすぎて並列度が足りないということであれば、kinesisへピボットする

■ ストリームへのデータ保持期間を24日以上にする必要があるか?

結論: 今のところ必要はないので、必要に応じてダウンストリームのkinesisに流し込む

■ data producerが増える可能性があるか?

  • kinesisはあらゆるソースからのストリームデータの収集が可能
  • DynamoDB StreamsはDynamoDB Tableのみ

結論: 活動履歴以外のモデルについては、DynamoDBではなくNeo4jというグラフDBに保存されているため、それらモデルについても非同期レプリケーション機能を採用しようとした場合、kinesis data stream1択になる。ただその場合、モデルごとに独立したストリームをこしらえることが予想されるので、kinesis data streamを複数のproducerで使いまわすことは考えにくいため、活動履歴用のストリームに対するdata producerを増やせるという利点にあまり魅力は感じない

■ コンシューマーが増加するかどうか

  • kinesis fenhanced fanoutなら最大20のコンシューマーにほぼリアルタイムのストリームデータを提供可能
  • dynamoDB streamの場合、最大コンシューマーは2つなので、間にsqsやkinesisを介したファンアウトパターン必須。

結論: 必要になればダウンストリームにkinesisを追加すれば良い

  • 重複コードへの対応、orderの順序担保をlambdaレベルで実装することを許容するか
    • kinesisの場合、信頼性(レコードが重複したり)、順序性(orderが担保されない場合)についてアプリケーションレベルで担保する必要がある。  

所感

上記の各判断材料を鑑みて実装コスト高いkinesis data streamを採用する理由は乏しいので、一旦DynamoDB Streamsを採用して、後にkinesisの需要が高まればダウンストリームとしてkinesisに流し込めば良い。

またDynamoDB Streamsで実装した際に、シャードのコントロールができない等の原因でストリーム詰まりが発生するようなら、データのESへのレプリケーションビジネスロジックはそのままで、streamとの繋ぎ込み部分だけkinesis用に交換すれば良い。

②ストリームのコンシューマーはlambdaで良いか
  • 同時実行数についての懸念
    • regionごとにlambda間での同時実行枠の取り合い
    • 活動履歴以外も全てlambdaを使用した場合、リアルタイム性を意識した小さなバッチサイズだと同時実行数を占拠し、他のlambdaをスロットリングさせる懸念。
  • 将来的に活動履歴以外のモデルのレプリケーションも実装する場合の統一性
    • 活動履歴以外はneo4jに保存されているので、パイプラインはkinesis data stream, コンシューマーはkclを使用したec2が採用される可能性が高く、活動履歴とアーキテクチャが異なってメンテしづらくなる。

所感: 活動履歴以外のデータのレプリケーション方法が上記の通りなら、コードの再利用性やアーキテクチャの統一性を重視して、lambdaではなく、DynamoDB Streams Kinesis Adapter を使用したKCLと同じインターフェースでのDynamoDB Streamsへの繋ぎ込みをec2上に展開するのはあり。

とはいえ、service quotaに引き上げという最終手段もあるので、実際に占拠される同時実行数の温度感などの検証も含めて、管理コストの低いlambdaでサクッと実装するのが本プロジェクトの温度感としてもちょうど良いかなと考える。

考慮事項

lambdaについての考慮事項 - シャードあたりの並列同時実行数(parallelization factor)

結論: 監視して、もしストリーム詰まりが発生するようなら、随時調整。 - pollingでのバッチサイズ - 2以上にしてしまうと、同じパーティションに対する変更が2回以上起こらないとesに同期されない。

結論: リアルタイム性が求められるため、バッチサイズは1 - polling間隔 - dynamoDB streamは1秒に4回 - kinesis streamは1秒に1回(ベースレート)

結論: batch windowでポーリング間隔を引き伸ばすことは可能だが、リアルタイム性の担保のため、いじる必要性はない - retry処理 - ストリームをイベントソースにするlambdaは同期的にシリアルに動くので、エラーが発生した場合、成功するか24時間経ってデータがストリームから削除するまで後続処理をブロックする

結論: リアルタイム性を担保するためにretry処理の最大試行回数を3,4回に設定し、上限を超えた場合はDLQへ。 - 同時実行数(ボトルネック) - スロットリングエラーが出た際は成功するまでretryをしてDLQに退避できないので、リアルタイム性を維持するために速やかなスケールが必要

結論: 現状の活動履歴の更新回数やシャード数(ほぼ1では?)では特にスロットルされる懸念はないので特に対策する必要はない。 様子を見てスロットル回数などのモニタリングを行い、適宜同時実行数の予約やservice quotaの引き上げなどを行う

遅延速度の検証

今回の設計でレプリケーションにどれくらいの遅延が生じるかも検証しなければなりません。

まずは現在のリクエストレートを算出し、それに準ずる負荷をかけ問題がないかを確認し、そのあとは逆の方向でどれくらいの負荷までなら耐えれるかを計算し、将来的なパイプラインのスケール性に目処を立てます。

リクエストレート算出フロー

現状のDynamoDB の本番テーブルのピーク時の消費キャパシティユニットから本番でのリクエストレートを算出します。

上記フローより、現状の本番環境では活動履歴の書き込み操作はピーク時のレートが分かりました。

負荷テストの実施方法

負荷テストツールを使う方法もありましたが、rakeタスクで自作し、達成したいリクエストレートが出るようにrubyの並列度を調整します。

1回目

観測されたリクエストレート: 1秒あたり20リクエス

2回目

2回目以降は、どのレートであればパイプラインがレイテンシ的に耐えられなくなるかの視点で行っています。

観測されたリクエストレート: 63回 / 1秒

並列度を上げたためかなり負荷がかかっており10秒以上同期が遅延してるのが読み取れますね。

3回目

2回目と同じリクエストレートで、lambdaの並列数を上げるとどうなるでしょうか。 DynamoDB Streamのためシャード数の調整はできないため、シャード数に応じたlambdaのスケーリングはできませんが、1シャードあたりのlambdaの並列度はParallelization Factorというlambdaのパラメータを調整することで~10並列までコントロール可能です。

この並列度を3にした結果、63回/1秒のレートでも遅延が大幅に減っており、アプリケーション要件を達成しうるものです。

4回目

ではこのParallelization Factorを限界の10に設定してもなお、遅延が抑えられないレートとはどの程度でしょうか。

下図の通り、200回/sのレートで送ってみた場合、lambdaの並列度を10にしても一部で5秒ほどの遅延が生じていることからこの辺りの負荷になってくると、現状のパイプライン設計がボトルネックを帯び始めることが分かります。

結論

現状の本番環境のリクエストレートを遥かに高くした負荷(20回/s or 60回/s)で検証したが、 20回/sの場合は、lambdaの並列度が1のままでも平均1秒以内にレプリケーションが完了していることが分かりますね。(実際は検索で使えるようになるまで、Elasticsearchのrefreshまでの時間がプラスで加算されます)

また、どの程度の負荷であれば現状のパイプラインでは耐えきれなくなるか検証したところ、 60回/sのレートで遅延が10秒以上発生するようになっていました。

しかしこれもlambdaの並列度を3にすることで、平均1秒強にレイテンシが抑えられることから、今後爆発的に活動履歴の書き込み操作のレートが上昇しても、検索できるまでの遅延を1, 2秒程度に抑えることが可能ではあるでしょう。

ただ、リクエストレートが200回/s程度に近づいた場合、DynamoDBの1シャードあたりのlambdaの並列度の上限である、10にしたとしても、一部のデータについては5秒ほど遅延が生じるため、これ以上のリクエストレートで遅延を大きくしたくない場合は、別の方法を考えなければなりません。

DynamoDBのシャードは、1つあたり以下の上限を持っています。 - ストレージが10GB - RCUが3000 - WCUが1000

ですので半ば無理やりこれらの値を調整し、シャード数に引き上げによる並列度のさらなる上昇も実現可能ではありますが、費用もバカにならずコストパフォーマンスは最悪ですので、シャードを自由に設定できてlambdaの並列度をほとんど制約なく上昇させられるKinesis Data Streamへの移行が必要になってきます。

とはいえ、ビジネスサイドと相談したところ、秒間200回のレートに達するのはまだ先のお話...

とりあえず、DynamoDBに対するレートのメトリクスを監視し、十分なバッファを持ってstream移行ができるよう体制を構築し、直近では今回の設計で問題なしということになりました。

感想

まず、今回重要だったのが”どれだけリアルタイムにレプリケーションを行えるかどうか”という点でした。 ユーザーの活動履歴をすぐに検索できる事が求められていたので、1分を超えるような遅延は実用的ではありません。

そういった中で、レプリケーションの時間を測定するためにログを仕込む必要が生まれ、そのログをキャッチするためにCloudwatchで独自のクエリを組まなければならないのですが、そこにはかなり苦労しました。やはり言語は無闇に独自仕様が生まれるのではなく、統一的な仕様があったほうが良いですね(笑)

また、Musubu本番で起きうるリクエスト例や、実際に負荷のかかるリクエストレートを想定し、データの生成をうまくシミュレーションして負荷をかけつつ、それに対して遅延問題のクリアを試みます。並列処理をしないと遅延が大きくなってしまうことが分かっていたので、Lambda関数などの並列度を上げながら色々試行錯誤し、

最終的にデータの整合性・堅牢性・冪等性といった考慮すべきところをクリアしたうえで、遅延3秒以内という実用的な数値に抑えることができてかなり嬉しかったです。実際にレプリケーションを行うという試みは技術的経験としては初めてのものだったので、今回の結果はかなり自信に繋がりました。

自分にとって、「大規模データ処理の世界」とは、まるで断崖絶壁のような答えの見えない世界だったのですが、今回の経験によって断崖絶壁の中に階段が生まれ、答えに辿り着く道筋が示されたような気分になりました。まだまだ奥が深いので、これから階段を少しずつ登っていきたいなどと考えています!

アプローチPDCA機能開発に伴うデータ移行について

はじめに

こんにちは!Baseconnectエンジニアの文です。 前回、弊社テックリードの朱に『MusubuのアプリケーションのRailsからGoへの移行』 として新たなプロジェクトへのアプリケーション側の移行について紹介してもらいました。

techblog.baseconnect.in

この新たなプロジェクト(『アプローチPDCA』と命名された)については、もう一つ大きな課題がありました。 記事中でも紹介がありましたが、DBの変更を行う必要があり、そしてそこには”データ移行”という大きな壁があったのです。

稼働中のシステム(以下:『rev1』と表記)はNeo4jというグラフ指向のデータベースをメインで使用しております。 プロジェクトで新たに開発するシステム(以下:『rev2』と表記)ではMySQLを採用するので、これまで蓄積されていたデータを移行する必要が出てきたというわけです。

本記事では、アプローチPDCAプロジェクトにおいて、Neo4j からMySQLにデータ移行を行うにあたって、どのように設計・実装・実行を進めたかということを紹介させていただければと思います。

移行対象データのサマリー

  • データ移行するテーブル数
    • 31
  • データ移行するレコード数
    • 約 5千万件
  • 参照するデータソース
    • Neo4j
    • Elasticsearch
    • DynamoDB

要件・実装上の制約など

当然、rev1 で蓄積した Neo4j の データをそっくりそのまま MySQL へ移行して rev2 で使用できるというわけには行きません。 データベースの性質の違いや、新システムrev2 を実装する仕様に合わせて一部データを追加、加工する必要があります。

中間テーブル問題

案件にタグを複数割り当てることができ、当然タグも複数の案件に割り当てることが出来ます。 いわゆる多対多の関係に該当するわけですが、Neo4jはグラフ指向のデータベースであり、データはノードとリレーションという形で表現されます。 MySQLなどのリレーションナルデータベースで多対多の関係を表現する際によく用いる中間テーブルが存在しません。 Neo4j上のリレーション構造を維持したままMySQL上に移植する必要があります。

仕様上のデータ移行要件

rev2 を新たに実装するにあたり、既存システムの rev1 とは仕様が異なりデータ構成のレベルで対応が必要になる部分も存在します。 取引先に保存していた住所のデータは基本的に都道府県を含む形で保存していましたが、都道府県の絞り込み検索を実現する関係で別プロパティとして都道府県データを保持していました。

これはデータの2重管理に近いような状態になってしまっており、rev2 の住所データからは都道府県を排除し市区町村以降の住所を保存するように仕様が定義されました。

それに伴い、データ移行を行う際にもそれに合わせて、データの加工を行う必要が出てきます。

テーブル名及びカラム名の変更

これは、要件的に必須というわけではなかったのですが、過去に定義したデータの名前がわかりにくかったり、運用を続ける中で実態と乖離が発生しているデータが存在します。 これをデータ移行することを機に、より明確で実態に合わせてテーブル名やカラム名を変更しておきたいというわけです。

その他データ以降を実施するにあたっての課題

データの依存関係

移行先のデータベースをMySQLを採用したことで、外部キー制約によるデータ依存関係が発生します。 データ移行を実行する順序についても設計が必要になります。

不正データへの対応

サービス運用開始当初から蓄積された rev1 のデータの中には、バリデーションが不十分な状態で作成された不正データや、不具合によって発生した不整合データなども存在します。 それらの不正データは直接データ移行が出来ないので、データ移行スクリプトを実装する際に考慮するもしくは、データ移行の実行前に不整合データの解消を行っておく必要がありました。

データ移行仕様書の作成

上記の通りデータ以降を実施するには多数の課題があります。 そのためデータ移行の要件を細かく記載したデータ移行仕様書の作成を行うことにしました。

仕様書の項目はだいたい以下を網羅する内容にしました。

▽データ移行仕様書の中の大まかな項目

  • 検討事項
  • 概要
  • 移行先テーブル
  • 参照データ
  • 移行するデータ
  • 依存関係

また、データの依存関係を考慮するとデータ移行を実行する順序についても検討しておく必要があります。 しかしながら、移行対象データの数も非常に多いので、データ移行手順書という形で、こちらについても細かく定義しておくことにします。

実装

データ移行の仕様書や手順書の作成が一通り完了してようやく実装開始です。 スクリプトPythonで実装しましたが、深い理由はないですが実装開始当初、実装担当者のアサインが定まっておらず、プロダクト開発メンバー以外でも着手できるようキャッチアップコストの少ない技術スタックを採用しました。

実装概要

データ移行の処理は大まかに分けて3ステップです。

  1. Neo4j等のデータソースからデータを読み取り、仕様書の内容に従って、データを加工し、CSVにエクスポートする
  2. エクスポートしたCSVファイルをS3へアップロードする
  3. LOAD CSV にてMySQLデータの読み込む

構成図

データ移行実行の冪等性の担保

運用前のデータベースに移行するということで、冪等性に関して気にする部分は少なかったですが、何度でもデータ移行を実行が行えるよう、移行元のデータに破壊的変更を加えることが無いように意識して実装しました。

動作確認と改善

ステージング環境は、過去のテストデータが大量に作成されており正しくデータ移行されている検証するのは困難で、運用中の本番環境に負荷をかけるわけには行きません。

そのためデータ移行の動作確認は、本番環境のスナップショットからデータベースを立ち上げて、新たに専用の環境を用意して実施しました。 いざ、データ移行を通して実行してみると想定以上に実行に時間がかかることがわかりました。

取引先のエクスポート処理だけで16時間 ...。インポートに4時間 ...。 これでは、2日確保したメンテンスの時間を使い切ってしまいそうな勢いです。

データ移行のパフォーマンス改善を行う必要がありました。 一番ボトルネックとなっていたデータ量の多いエクスポート処理については、並列実行する様に改善し、インポート処理の改善には、一時的にデータベースのスペックをあげることで対応しました。

本番実行

データ移行のパフォーマンス改善を実施したものの本番環境のデータ移行には想定以上に時間がかかりました。 動作確認用に作成したクローンのデータベースから移行テストを行っていましたが、作成から本番データ移行を実施するまでに5ヶ月程度あり、その間に増加したデータが想定以上に多かったことが原因でした。

また、データ移行後のアプリケーションからの動作確認で、不備が見つかる場面もありましたが、データ移行実行に関しては冪等性を担保出来ていたので、スクリプトの修正を行い再度実行することが出来ました。

成果とまとめ

データ移行の検討を始めた当初は、どのようにすすめて行けばよいかイメージしづらかったのですが、大規模で複雑なデータ移行を実施するにあたっても、一つひとつ手順を分解して明確化していくことが重要であると痛感しました。

データ移行仕様書や、手順書を定義していくことに注力する中でかなり手順を明確化することができ、実装に着手する段階ではすでに勝負が決していたような感じでした。

実際の動作確認してみるパフォーマンス問題に直面しましたが、処理の並列化などの対応をしていく中でも、仕様書に定義された要件を満たすことに集中すればよかったので、テストも行いやすかったですね。

今回はアプローチPDCAのデータプロジェクト内で実施したデータ移行の設計や実装、改善といったプロセスを中心に紹介してみました。 本記事内で実装の詳細な技術的な部分に触れた部分は少なかったですが、複雑なデータ移行を実施する際の参考にしていただければ幸いです。

MusubuアプリケーションのRailsからGoへの移行

自己紹介

はじめまして!Baseconnectのエンジニアの朱です。 私は2019年に入社してからバックエンドエンジニアをしており、DBA、テックリードのロールを努めています。

今回、弊社のプロダクトである「Musubu」で、新たなプロジェクトを開発するにあたり、古いDBのライブラリの制約や、それに伴う様々な難しい条件と対峙することになりました。

この記事では、それらの条件をクリアしていくために議論したことや、実際にRailsからGoへ部分的に置き換えた事などを紹介してみようと思います。

現状

Baseconnectに入社したときには、すでにNeo4jをメインDBに、Elasticsearchを検索用のDBとして採用されており、アプリケーションのバックエンドはRailsによって書かれていました。 簡単に構成をまとめると、以下のような感じです。

  • アプリケーションのバックエンドの言語
  • DB
  • メインDB: Neo4j
  • 検索用: Elasticsearch

Baseconnectには一般外部公開の企業情報提供サイトと、企業データと営業活動を結びつけて支援する主要プロダクトであるMusubuがあり、両方とも上記のアーキテクチャになっていました。

今回の記事で紹介する移行は、主力事業のMusubuで行われたものです。

新しいプロジェクトに向けて

Musubuには大きく分けて、

  • 企業データの検索機能
  • 企業データと連携したユーザーの営業データ管理機能

の2つがあります。 このうち、”「営業データ管理機能」を刷新して強化をする" という事業戦略が出てきました。

実際にビジネスと打ち合わせながらその設計を進めていくうちに、データモデルと機能の大幅な刷新が必要であるという事が浮き彫りになってきました。 しかし、既存のシステムのアーキテクチャでは、それらを実現するためにはいくつかの障壁があったのです。現状の整理をし、出てきた問題点を紹介したいと思います。

Neo4jの問題

『Neo4j』とはグラフDBの一種です。パナマ文書の解析で脚光を浴び、その名前が広く知られるようになりました。 Neo4jは複雑なグラフ構造を、RDBよりも簡単に表現でき、その検索を高速に行うことができることを特徴としています。

しかしながら、現状のアプリケーションでは、採用された当初で想定していたほどにはこの特性が必要とされておらず、Neo4jを採用するメリットが極めて薄い状態になっていました。

また、Neo4jを利用するクライントのほうも問題がありました。

Neo4jのORMが activegraphであり、内部で依存しているドライバー(neo4j-ruby-driver)が、Neo4j公式サポートのものではないという事です。Neo4jはそもそもRuby言語自体を公式ではサポートしておらず、Rubyのサポートはコミュニティ開発によって支えられているのが現状です。 また、ドライバー自体のスレッドセーフティに問題があり、アプリケーションをプロセスごとで起動せざるを得ませんでした。 そして追い打ちをかけるように、ORMの最新のメジャーバージョン11では、CRuby自体のサポートが切られて、Neo4j自体のバージョンの更新もままならない状態に至っていました。

Elasticsearchとの同期問題

システムでは、Neo4jでは足りなかった検索性能を補完するために、Elasticsearchが使われています。 例えば、Musubuにおける企業検索機能の複雑な検索や、検索条件に応じたリアルタイムの集計機能といったNeo4jでは実現が難しいところを、Elasticsearchが担っています。

あくまでDBのメインはNeo4jなので、データの変更があった場合はそれをElasticseachに逐次反映させる必要があります。この「複数DBの更新」という行為が、トランザクションの制御や、更新トリガーの漏れといった問題を容易に引き起こし、結果かなりのデータのずれを引き起こしていました。 そして、その都度データの確認と修正を行っていたために、エンジニアのリソースがかなり割かれていました。


こうして多くの問題が浮き彫りになっていく中で、やはり一番大きな問題はデータの一貫性の保証でした。 ORMサポートの停止によっていよいよNeo4jの延命措置もできない。刷新されるモデルにNeo4jの実装が耐えられないのであれば、メインDBを変えなければならないのでは、という議論が持ち上がりました。

Goを使うという提案

DBを変更するとなると、アプリケーション自体もほぼ書き直しをせざるを得なくなります。 そこで、どうせやるなら、「Railsのままではなく、Goでやったらどうか」という提案を私がしました。 Goを提案した理由は、

  • 静的型付け言語の世界を経験してみたい
  • Rails 以外の開発を経験したい

とわりとラフでした。 バックエンドのメンバーからの反応は悪くありませんでした。しかし、全員ほぼ未経験の言語をいきなり採用するというリスクはかなり大きいものになります。 開発に携わるメンバー間で、Railsのままでやるという選択肢も含めて、他の言語の選択肢なども探り、何回か議論を重ねました。 Goを検討するにあたって出てきたものは簡単にまとめると以下のような感じです。

▽メリット

  • 型が厳密で、コード品質が上がる
  • 学習コストが比較的に低い
  • コンテナ運用がしやすい

▽デメリット

  • ほぼ全員が未経験で、どうなるのか予想できない
  • Rails のようなフレームワークがなく、ディレトリー構造ですらも考える必要がある

Goは静的型付けによるアプリケーション開発の品質向上が期待でき、また同じような他の言語より移行の学習コストが低く、並行性のパフォーマンスの高さなどが注目されていました。 一方で、採用の難しさや、失敗事例の存在など、反対意見ももちろん出てきました。 しかし、Goにチャレンジしてみたいという気持ちと、それを支持してくれたマネージャーたちがいたことで、経営レベルの採用の判断に繋がりました。

Goによるリプレイス

Goへのリプレイスを、既存のアプリケーション全てで行うというのは現実的ではありません。あまりにもシステムが大きすぎるからです。 そこで、機能領域で分割し、営業リストの機能をGoでリプレイスして、それ以外の機能はRailsに残すことになりました。

まず、ベースの実装として弊社のアーキテクトの大槻が一人で進めて行くことになりました。 そしてそれをベースとして、Goの経験が初めてのエンジニアメンバーで実装していく進め方を取ることにしました。

アーキテクチャの刷新

現状のシステムでは、Railsアーキテクチャに限界を感じている部分がありました。 RailsMVCで作られていますが、モデルのオブジェクトとデータが密結合で、複数のモデル(M)をまたがった処理(ビジネスロジック)を書く場所が用意されていません。

この部分に対する解釈は人によってかなり異なっていて、社内のルールもありませんでした。 その結果として、『アカウント』などの汎用的なモデルが超巨大になったり、特定のモデルのルールが他のモデルのメソッドに書かれていたり、コントローラー(API)にすべて詰め込まれたりと、全体がカオスになり、把握が困難で、実装時の事情を記憶している人に頼らざるを得なくなっていました。

無論、これらの問題は単純にアーキテクチャだけに起因するものではないのですが、アーキテクチャを変更することで、かなり改善する見込みがありました。そこで、軽量DDDとクリーンアーキテクチャを採用することになりました。

DDDとは、ドメイン駆動設計(Domain-Driven Design)の事であり、複雑なソフトウェアを設計・開発するためのアプローチです。ビジネスの専門知識やルールを、「ドメイン」と呼ばれるモデルに落とし込み、それをソフトウェア設計の中心に置きます。

そしてクリーンアーキテクチャは、この中心となるドメインを、フレームワークやDBなどに依存しないように関心の分離を行うことで、機能の改修や開発、バグ修正などを行いやすくするための設計方法です。

ここでは詳しく説明しませんが、これらの技術スタックに関しては世の中にかなりの数資料があるので、興味がある方は調べてみてください。

私は、これらのDDDやクリーンアーキテクチャについては概念としておぼろげな理解はあり、そういう形でアプリケーション開発をしてみたいと思ってはいたものの、実際には実装した経験はありませんでした。

開発がスタートし、やっている最中は、常に検索して資料を見つつ、相談しつつ、実装していきました。 中でも、一番悩ましかったのは、パフォーマンスとコードによる仕様の表現の綺麗さという点でした。

Musubuでは営業のためのリストを扱いますが、リストの中身の件数が多くて、その処理のパフォーマンスがユーザーの体験に直結するため、常にそのパフォーマンスを考慮する必要があります。

しかし、パフォーマンスのための最適化をやりすぎると、コードによって表現すべき仕様がわかりづらくなり、潜在的なバグになりかねません。パフォーマンスをあまり損なわないところで、コードのクリーンさをどこまでどう保つかということが、議論や相談のポイントになっていました。

リプレイス後のコードでは、クリーンアーキテクチャによるレイヤー分けと、その責務が意識化されました。

それによって、どこに何を書くべきかの範疇が以前よりもかなりはっきりしていて、同じロジックのコードの分散の問題がかなり解消されました。また、単体テストもレイヤー間の疎結合によってしやすくなっており、ほぼAPIのテストしか書かれていなかった時から、安心してコードの再利用ができるという状態になりました。

Go リプレイス後

具体的な恩恵を紹介してみたいと思います。

厳密な型による恩恵

Ruby (on Rails) のコードでは、特定のメソッドの使用を、文字列の検索を使って人力でやる必要があり、全部網羅できているかの不安が常につきまとっていました。

特に、Rubyメタプログラミングを利用したコードが、メソッドの利用状況を隠蔽し、インテリセンスを混乱させるため、更に不安を増大させます。また、メソッドの引数の型が明らかでない場合に、そのメソッドの呼び出しのコードから割り出す必要があったり、そもそも、モジュールの参照先が非常にわかりにくいために、メソッドの定義そのものを探したり、定義のコードを読み解くのに、周辺のコードの習熟する必要がありました。

一例として、次のようなコードで、

class Model
    attr_accessor name
    
    include ModelModule
    
    def hogehoge
        hoge # この hoge はどこからきた?
    end
end

## 別のファイルに

module ModelModule
    def hoge
        puts name # この name はいったい何??
    end
end

hoge メソッドを読むときに、name という変数ないしはメソッド呼び出し(それすら文脈がないと、判断できない!)に出会ったら、これはいったいどこに定義されているものかは、元のモデルのクラスについて熟知していないと、読み解くことが難しいといえます。

逆に、hogehoge メソッドで hoge を呼び出しを行っていますが、モジュールの中身を知らないと、hoge が唐突に感じます。こういったコードは、Rails のコードではよく見かけるのではないでしょうか。このように短いコードで、クラスとモジュールの定義が近くにあると実感しにくいですが、モジュールが何個もあって、モジュールのコードが全然別の場所にあると、これを読み解くのがかなり労力がかかる事になるでしょう。

同じようなコードを Go に書き換えると、以下のようになります。

type Model struct {
    Name string
}

func (m *Model) hoge() {
    fmt.Println(m.Name)
}

func (m *Model) hogehoge() {
    m.hoge()
}

どうでしょう。メソッドなのか、フィールドなのかは一目瞭然になったのではないでしょうか。フィールドがすべてstructで定義されるので、(同列では語れないが)突然インスタンス変数が追加されることもありません。(*注:Go には Ruby の mix-in にそこそこ近い機能として、構造体の埋め込みがあるが、埋め込まれた構造帯のメソッド内では、埋め込み先の構造体のフィールドにアクセスできない。)

すべてのメソッド、構造体のフィールドの追跡が、Go の 公式 Language Server (gopls) によって確実にできるようになっているので、部分的にでも読み解くことも容易です。また、typoの検出、リファクタの実施が容易にできるようになりました。

これによって、開発体験とコードの堅牢性がかなり上がったと感じます!

アーキテクチャの変更による恩恵

リプレイス後のシステムでは、クリーンアーキテクチャによって、アプリケーションにレイヤーができ、各レイヤーの役割が明確、かつ、疎結合になっています。

かつてのように、DBからAPIまでのすべてを結合しての複雑なテストが不必要になり、シンプルな単体テストが大幅に拡充され、テストの実行時間も短縮されました。

DBから切り離されたドメイン層ができて、ビジネスロジックドメイン層で実装するというルールができ、複数のエンティティ(Rails でいうモデルの近い)に跨る処理は、集約ないしドメインサービスで書かれるようになりました。

ドメイン層で実装されたこれらのコンポーネントが、複雑なユースケース層を実装する時に再利用できるようになりました。これによって、実装者が毎回すべてのデータの運用ルールをすべて把握した上で実装する必要がなくなり、実装者もコードレビュアーも認知負荷が下がり、把握漏れによるバグが大幅に減りました。

アウトロ

ここではDB上の制約に立ち向かうために、RailsからGoへの置き換えを実際に進めた経験を紹介してみました。 また、記事中でも触れましたがメインDBの変更も今回は行われており、そちらは弊社の文が記事を書いてくれています。

techblog.baseconnect.in

私自身、振り返ってみるとクリーンアーキテクチャをちゃんとした形で実現できていない部分もあるな、という感想もあります。設計・実装時点では、Goでクリーンアーキテクチャをサポートするようなライブラリ等のデファクトスタンダードがこれといって見つからず、都度手探りで進めていきました。

C#Java等の他の言語でクリーンアーキテクチャを実現している例などを参考に、当時はGoに落とし込めていたと思っていても、実装が終わり、理解が深まった今、見返してみるとやはり不完全な部分があるなと感じてしまいます。

一方で、既存のシステムの中枢アーキテクチャであるRailsという枠組みから離れ、Goという新たな試みによる挑戦。そして、その中でほぼ自力でアプリケーションを構築し、設計から細部までを自分たちで考えて作り上げた事は、アーキテクチャやGo自身の理解と習熟に繋がり、自信が生まれました。もちろん苦労した分、愛着もあります(笑)

リプレイスは簡単な事ではなく、時には困難な事もありますが、しかしそれを補って余りあるメリットもあると言えます。 私の記事が、皆さんのGoへのリプレイスや、Goで新たなプロジェクトを立ち上げるきっかけや参考になれば幸いです!

開発チームでOSTをやってみました!

こんにちは、開発部門の採用や組織改善に携わっている寺尾です! 今回8/9に開催したオフサイトMTGで、OSTをやってみたので、その内容を記事にしたいと思います。

オフサイトMTGの詳細についてはこちらの記事をご覧ください!

techblog.baseconnect.in

はじめに

午後からは、はじめて開発チーム全体でOST(Open Space Technologyの略)をやってみました。OSTの特徴は、用意されたアジェンダはなく、参加者が主体となって対話を進める点です。

参加者自身がディスカッションしたいと思っているアイデアや課題などを自由に持ち寄り、自分達で話すテーマを決めることが出来ます。詳しいやり方は、今年のはじめに参加した、スクラムのカンファレンス「Regional Scrum Gathering Tokyo 2023」での体験をベースにさせてもらいました。

狙い

OSTを取り入れた理由としては、リモートメインの働き方をする中で、チーム全体で意見を出し合ったり、自発的なアイデアを直接共有できるような機会が減っていたので、チーム内の交流や意見交換、そこから次のアクションに繋がるようなきっかけ作りになればと思い、実施しました。

実際にやってみてどうだったか

OSTは、雛壇のような階段が連なるオープンな場所に移動して行いました。 (事前の会場見学で、実施するのにぴったりなのでは!と思い、選んでいます😁)

まずは動画を流し、イメージを深めてもらいました。

次にスライドを使って、具体的なやり方について説明していきます。

そして、いよいよ話したいテーマを考えてもらう時間になりました。今回は大きな枠組みとして「Baseconnectの開発チームに関すること」であれば何でもOKとしました。1人、最大1テーマとし、書けたメンバーから前に出て順番に発表してもらいます。

どんなテーマが出てくるんだろう?とドキドキしていましたが、

- 「品質とは」「クオリティを上げるには」
- 「より良い開発チームになるための行動規範」「どんなチームになりたい?」
- 「How to be good leader」
- 「開発プロジェクトにアジャイルを使うべきなのか?使わなかったらどうするべきか?」
- 「Baseconnectの開発チームで探求していくべき技術とは」「開発チームとして作りたいサービス・プロダクト」

など、沢山の面白そうなテーマが出てきました!

そこから、全員で集まったテーマを見ながら、1ターン20分×2のタイムテーブルを作っていきました。「このテーマと、あのテーマを一緒に出来そう!」など、声が上がり、すでに参加者皆で作り上げるOSTの雰囲気が出ていて、とっても嬉しかったです。

タイムテーブルが決まってからは、テーマごとの主催者が、設置したイーゼルパットの元に集まり、いよいよディスカッション開始です。それぞれが興味のあるテーマに集まって、付箋を使って、意見を出し合いながら会話が進んでいきました。

  • 自分はこういう考えを持ってるけれど、皆はどう思う?
  • 〇〇という考えがあるけど、こういう意味を持たせられるんじゃないか?

など、様々な視点からの意見や考えが交わされて、大盛り上がりでした。

さいごに

今回、社内ではじめてのOSTを開催するにあたって、運営メンバーで予行練習をしつつも、やってみないと分からない要素が多かったのですが、実際に開催してみると、参加してくれたメンバー全員の協力の元、沢山のテーマが集まったり、ディスカッションも盛り上がって、とても楽しい時間を過ごすことが出来ました!

開催後のアンケートからも、ポジティブなコメントをもらえて、感謝の気持ちで一杯です。

- 色んな人達と話せてとても楽しかったです。OSTはまたやりたいです。
- サービス・戦略をいかに大きく改善するか、いかに仕事を楽しむか、という様な前向きな議論をできたことが非常に良かったです。
- 場所がよかったです。案外みんなが話したいお題をもっていて、盛り上がってよかったです。
- リモートで一人で悶々と仕事をしているだけだとフラストレーションも溜まりやすかったですが、オフラインで皆と話せてとても楽しかったです。

また、時間内で話しきれなかった内容や、各テーマごとにどんな話題が出たのか?など、気になる部分も多かったので、開発チーム内で月1回開催しているDeveloper Closer内で共有会を実施することになりました。

実施後もこういった取り組みに繋げることが出来て、とても良かったと思います!

今後も色々なワークショップなどを試しながら、リアルでのコミュニケーションの機会も大事にしていけたらと思います。ありがとうございました!

今年も開発チームのオフサイトMTGを開催しました!

こんにちは、プロダクト開発チームの富田です! 昨年に引き続き、今年もエンジニア全員がオフラインで集まり、色々なことにチャレンジしたので、記事にしてみたいと思います!

昨年の記事はこちらからご覧下さい。

techblog.baseconnect.in

どこで開催したの?

今回は、京都のQUESTIONさんで開催しました。

実はここは、オフィスから徒歩5分程度だったりします。 オフィスの近くにこんなステキな場所があるなんて、、、

午前中は会議室風の部屋を、午後からはすり鉢状になっているカンファレンスルームを使用しました。

目的や狙い

現在、Baseconnectでは、ほとんどがリモート作業になっています。

チャットツール上では、業務の話が中心となり、思っていることや、共有したいこと、提案してみたいことがなかなか表現しづらくなっています。

実際に会って話すことで、日頃言えないことをお互いに共有し合って、改善のキッカケになればと思いました。

気をつけたこと

このミーティングで何かを決定したり、成果物を作ることはなく、あくまでキッカケ作りということを重視しました。

何かしらの成果物を作ろうとすると、それを達成するためにどうするか、ということが目的となってしまい、共有や議論のような「目的」としているものと離れてしまうと思ったからです。

最近話題のネガティブケイパビリティを重視する感じです。

どんなことをしたの?

今の気分

到着した方から、今の気分を付箋紙に書いてホワイトボードに貼ってもらいました。

自分の気持ちと向き合ってもらい、ワークショップに対する心の準備も行ってもらう目的です。

ウェルカムワークショップ

まずはウォーミングアップです。

こちらで紹介されている、「ウソホント」ゲームを行いました。

ワークショップは、ワイワイと盛り上がり、だんだんとオフラインのコミュニケーションの感覚を思い出してもらいました。

今と未来を考える

「発散」フェーズとして、ふりかえり手法の「熱気球」を行いました。 やり方は、こちらを参考にさせて頂きました。

「熱気球」は何度かチームでは使ったことがあるのですが、今回工夫した点としては、「Baseconnectのエンジニアとして、上昇するって何だろう?」ということも、それぞれのメンバーで考えてもらいました。

エンジニアは全員が同じチームで仕事しているわけではないので、それぞれの目的意識や現状の課題は違います。 違うのは当然のことなので、それぞれの価値観の違いを再認識してもらい、共有してもらいました。

また、何か結論やTryを出すのではなく、思っていることを共有して「どうすればいいんだろう?」「こんな風にやってみたいんだけど?」というような午後のディスカッションにつなげるアイデアを出してもらうようにしました。

「熱気球」完成後は、チームごとにどんな会話をしたのか発表してもらい、全体で共有しました。

Open Space Technology(OST)

ランチタイムをはさみ、午後はOSTを行いました。 詳細はこちらからご覧下さい。

techblog.baseconnect.in

共有

OSTの後、今回のミーティングについて感じたことを全員に発表してもらいました。

付箋紙1枚に感想を記載して発表してもらい、ホワイトボード(壁がボードになっている)に貼って行ってもらいます。

  • 楽しんだこと(Fun)
  • 学んだこと(Learn)
  • やりたいこと・やるつもりのこと(ToDo)

これは、FunDoneLearnというふりかえりの手法を元にして、少しアレンジさせてもらいました。 この一日を各自の中でふりかって整理してもらい、他のメンバーに共有することで一体感を感じてもらいました。

運営してみての感想

当初どうなることかと思っていましたが、参加者皆さんの協力で素晴らしい会になったと思います!感謝します!

AWS Summit Tokyo 2023:セッション、探索、そしてインサイトに満ちた冒険

こんにちは、BaseconnectのエンジニアのEndratno Alvinです!今回、AWS Summit Tokyo 2023に参加してきたので、体験したことや学んだこと、気づいたことを記事にしたいと思います。

背景 - AWS Summit Tokyo 2023に参加を決めた理由

私はR&Dエンジニアとして、クライアントの方にインサイトを提供し、大量のデータを処理できるデータプラットフォームを構築するために、チームと一緒に取り組んでいます。私たちは、様々なクラウドコンピューティングソリューションを探求しており、AWSさんは常にこの分野のトップと信じています。

ですから、AWS Summit Tokyoイベントについて聞いたとき、私は参加したいと思いました。AWSさんのサービスやツールについてできるだけ多くの情報を集め、より信頼できてスケーラブルなプラットフォームを構築するためのヒントを得たかったのです。

しかし、私がこのイベントに参加する理由は純粋に仕事だけではありませんでした。私はAWSさんの大ファンであり、最新の開発や革新についてもっと学びたいと思っていました。そしてもちろん、このイベントを業界の他のプロフェッショナルとネットワークする絶好の機会と見なし、新しいつながりを作ることができる可能性があると考えていました。

As a Research and Development Engineer at Baseconnect, my team is working to build a data platform that can handle large volumes of data and provide insights to our clients. We've been exploring various cloud computing solutions, and AWS has always stood out as a leader in the field.

So when I heard about the AWS Summit Tokyo event, I knew I had to attend. I wanted to gather as much information as possible about AWS services and tools that could help us build a more robust and scalable platform.

But my reasons for attending the event weren't purely professional - as a big fan of AWS, I was also excited to learn more about the latest developments and innovations in the field. And of course, I saw the event as a great opportunity to network with other professionals in the industry and potentially make some new connections.

AWS Summit Tokyoについての簡単な説明

AWS Summit Tokyoは、Amazon Web ServicesAWS)さんが主催する年次イベントで、クラウドコンピューティング、AI、機械学習、サーバーレスアーキテクチャなど、最新の技術動向について、ユーザーやパートナー、専門家が集まって学ぶ場です。

今年のイベントは、COVID-19後、初めてのオフラインサミットであり、前回のAWS Summit Tokyoから4年がたちました。イベントには基調講演、ブレイクアウトセッション、ハンズオンラボ、パートナーエキスポ、そしてCertified LoungeやDeepRacerなどの特別エリアがあります。

AWS Summit Tokyo 2023の最初のセッションの写真

AWS Summit Tokyoは、業界のプロフェッショナルが学び、ネットワークを構築し、自分たちの経験や専門知識を共有する絶好の機会を提供してくれます。

The AWS Summit Tokyo is an annual event hosted by Amazon Web Services (AWS), bringing together users, partners, and experts to learn about the latest developments in cloud computing, AI, machine learning, serverless architecture, and more. ​ This year's offline event was the first summit after COVID-19 and marked four years since the last AWS Summit Tokyo. The event included a keynote address, breakout sessions, hands-on labs, partner expo, and special areas like the Certified Lounge and DeepRacer.

The AWS Summit Tokyo provides a great opportunity for professionals in the industry to learn, network, and share their experiences and expertise.

セッション

AWS Summit Tokyoでは、クラウドコンピューティング、AI/ML、サーバーレスアーキテクチャなど、様々なトピックをカバーした10のセッションに参加する機会を得ました。

AWS Summit Tokyo 2023で発表されたセッションの写真

以下は、私がイベントで特に印象に残ったトップ3のセッションです。

  1. 今踏み出す、変革への一歩

AWSジャパンのCEOによって最初に行われました。彼はAWSが日本で成長し、様々な企業や政府機関に対してどのように支援してきたかについて共有して下さいました。また、AIスタートアップやAmazonが提供する幅広いモデルから選択肢を選ぶ柔軟性を提供する新しいサービスであるAmazon Bedrockが発表されました。利用できるようになったら、ぜひ私も試してみたいと思っています。

  1. AWS の徹底活用で ”守りの IT” から ”攻めの IT” そして "DX” へ

日本気象株式会社からの代表者によって行われました。オンプレミスシステムに直面した会社が直面した課題や、クラウドの採用に重点を置くこと、エンジニアのトレーニングとAWS認定報酬の提供、そしてAWSさんに助けを求めることで、克服した方法について説明して下さいました。最終的に、クラウドを成功裏に活用するだけでなく、短期間でサーバーレス技術を使用したアプリを構築することにも成功されています。

  1. Java on Lambda のコールドスタートを乗り越える、これからのサーバーレスアプリケーション

AWS LambdaでJavaを使用する際のコールドスタート問題を乗り越えるためのヒントやベストプラクティスについての話でした。サーバーレスアプリケーションを実行する際に、アプリケーションのパフォーマンスを向上させ、レイテンシを低減する方法についてインサイトを説明して下さいました。

During the AWS Summit Tokyo, I had the opportunity to attend 10 different sessions covering a range of topics in cloud computing, AI/ML, and serverless architecture. ​ Here are my top three sessions from the event:

  1. 今踏み出す、変革への一歩: This was the first session of the event and was presented by the CEO of AWS Japan. He shared how AWS has grown in Japan and helped many companies and government organizations in various ways. He also announced a new service called Amazon Bedrock, which provides flexibility to choose from a wide range of models built by leading AI startups and Amazon to find the model best suited for your needs. I'm excited to try it out once it becomes available.

  2. AWS の徹底活用で ”守りの IT” から ”攻めの IT” そして "DX” へ。: This session was presented by a representative from Nippon Kasei, a weather forecasting company. He discussed the challenges the company faced with on-premises systems and how they overcame it by doubling down on cloud adoption, providing training and certification rewards for engineers, and getting AWS to help them grow. In the end, they not only successfully utilized the cloud, but also built an app with serverless technology in a short timeframe.

  3. Java on Lambda のコールドスタートを乗り越える、これからのサーバーレスアプリケーション: This session covered tips and best practices for overcoming the cold start problem when using Java on AWS Lambda. The speaker provided insights on how to improve application performance and reduce latency when running serverless applications.

ブース

スポンサーブース

AWS Summit Tokyoでは、AWSさんと他の企業とのさまざまなブースが展開されました。私はデータプラットフォームに興味があるため、既存のデータウェアハウスにデータを統合し、AI/MLの目的に活用するためのツールを探していました。残念ながら、ブースで提供されているサービスのほとんどは、DevOps、セキュリティ、コンサルティングサービスなどのトピックに焦点を当てており、私のユースケースに関連するものはあまりありませんでした。

At the AWS Summit Tokyo, there were a variety of booths from both AWS and other companies. As someone interested in data platforms, I was specifically looking for a tool that could help integrate data into our existing data warehouse and utilize the data for AI/ML purposes. Unfortunately, most of the services available at the booths focused on topics like DevOps, security, and consulting services, with only a few being relevant to my use case.

AWS Summit Tokyo 2023におけるアイレット株式会社さまのブースの様子

AWSブース

運がいいことに、AWSブースで価値ある情報を見つけることができました。まず、カスタマーサービス代表として機能するボットを作成することを希望していることを専門家の方に相談してみたところ、Amazon KendraとAmazon Lexという2つのサービスを紹介してもらい、実験してみたいと思っています。

2つ目に、AWSパートナーになることの利点について知れました。さらに調べた結果、私たちの会社がAWSさんの専門知識やサービスを活用してビジネスを拡大するための素晴らしい機会になると考えています。

AWS Summit Tokyoでは、AWSさんによって特別なスタンドが設置され、参加者にユニークでインタラクティブな体験を提供しました。残念ながら、参加者の方とのネットワーキングは思ったほどできませんでしたが、これらのエリアを探索するのはとても楽しかったです。私が注目したいくつかのものを紹介します。

私がAWS Certified Loungeの前で3つのステッカーを持っている写真

  1. Certified Lounge: AWS認定プロフェッショナル専用のエリアでした。参加者は、認定レベルに応じたステッカーを受け取ることができました。私はAWSの認定資格を6つ持っているので、すべてのステッカーがもうすでになくなってしまったことに少しがっかりしました。

  2. AWS JAM: パズルを解いたりチャレンジをクリアすることを目的としたチーム対抗のゲームでした。他の参加者が参加する様子を見る機会があり、楽しみながら学び、他の参加者とのネットワーキングができる良い機会のように思えました。

  3. AWS DeepRacer: AWS DeepRacerは、AIモデルを構築して、他の参加者のモデルと競争するハンズオンアクティビティでした。私自身はモデルを構築する機会はありませんでしたが、他の人たちがモデルを構築し、競争する様子を見るのはとても興味深かったです。

AWS Summit TokyoにおけるAWS DeepRacer

AWS Summit Tokyoを通じて、楽しくインタラクティブな方法でAWSサービスやテクノロジーと関わるユニークな機会を得ることができました。ネットワーキングは、特に大規模なイベントやカンファレンスの場合は難しい場合がありますが、私はこのイベントから貴重なインサイトと経験を得ることができました。

Fortunately, I found valuable information at the AWS Booth. First, I spoke with an expert about our desire to create a bot to act as a customer service representative, and they introduced me to Amazon Kendra and Amazon Lex, two services that I am eager to experiment with.

Second, I learned about the benefits of becoming an AWS partner. After researching it further, I believe that proposing this to my manager could be a great opportunity for our company to leverage AWS expertise and services to grow our business.

At the AWS Summit Tokyo, several special stands were set up by AWS, providing attendees with unique and interactive experiences. Unfortunately, I didn't get to network with other attendees as much as I had hoped, but I still had a great time exploring these areas. Here are a few that caught my attention:

  1. Certified Lounge: The Certified Lounge was an area exclusively for AWS-certified professionals. Attendees could receive stickers according to their certification level. As someone with six AWS certifications, I was disappointed to learn that they had run out of stickers for some of the certification levels, and I only received three stickers.

  2. AWS JAM: AWS JAM was a team-based game that involved solving puzzles and completing challenges. I had the opportunity to watch others participate, and it seemed like a great opportunity to network with other attendees while having fun and learning. ​

  3. AWS DeepRacer: AWS DeepRacer was a hands-on activity that involved building an AI model and racing it against other attendees' models. I didn't have the chance to build a model myself, but it was fascinating to watch others build their models and compete against each other.

AWS Summit Tokyo provided a unique opportunity to engage with AWS services and technologies in a fun and interactive way. While networking can be challenging, especially in larger events like conferences, I still gained valuable insights and experiences from the event.

最終的な感想

AWS Summit Tokyoに参加することは素晴らしい経験でした。異なる業界や多くのエンジニアやプロフェッショナルがAWSサービスやテクノロジーについて学ぶために集まる様子は素晴らしかったです。イベントは活気に満ち、多数の企業が自社のサービスや製品を展示していました。

AWS Summit Tokyo 2023会場で記念撮影

AWSさんは本当に大規模な企業であり、彼らの運営の規模や提供する多岐にわたるサービスの幅を見ることは印象的でした。多くの方が参加されており、とても楽しく、情報もたくさん得られるイベントでした。

私がAWS Summit Tokyoから得た重要なことは、Amazon Bedrockを使ってAI/MLモデルの柔軟性を理解すること、そしてカスタマーサービスボットを作成するためのAmazon KendraとAmazon Lexの可能性を探求することでした。

まとめると、AWS Summit Tokyoはクラウドコンピューティング機械学習などの最新のイノベーションやトレンドについて学ぶ絶好の機会でした。この経験に感謝し、今後もこのようなイベントに参加することを楽しみにしています。

Attending the AWS Summit Tokyo was a fantastic experience. It was amazing to see so many engineers and professionals from different industries and backgrounds come together to learn about AWS services and technologies. The event was bustling with activity, and there were numerous companies showcasing their services and products.

AWS is a truly massive company, and it was impressive to see the scale of their operations and the wide range of services they offer. Despite the crowds (which can be overwhelming for some, including myself), the event was incredibly fun and informative.

My key takeaways from the AWS Summit Tokyo include understanding the potential of Amazon Bedrock for AI/ML model flexibility, learning how AWS services helped companies like Nippon Kasei overcome on-premises limitations, and exploring the possibilities of Amazon Kendra and Amazon Lex for creating a customer service bot.

In conclusion, the AWS Summit Tokyo was a great opportunity to learn about the latest innovations and trends in cloud computing, machine learning, and more. I'm grateful for the experience and look forward to attending more events like this in the future.

A Visitor's Guide: What to Expect at an AWS Summit

Hi, I am Endratno Alvin, an engineer at Baseconnect! I attended the AWS Summit this year and would like to share with you an overview of the event.

Attending AWS Summit Tokyo 2023 was an unforgettable and immersive experience. This premier event, hosted by Amazon Web Services, offers a unique opportunity to connect with like-minded professionals, expand your knowledge, and discover the latest innovations in the cloud industry. In this blog post, I will share my personal insights on what you can expect at an AWS Summit, based on my time at the Tokyo event.

Warm Welcome and Registration

Upon entering the building, I was greeted by numerous friendly staff members who guided me to the reception area. I received my name tag, which was essential for navigating the event and understanding the roles of others. At AWS Summit Tokyo 2023, the name tag colors indicated: black for visitors, white for staff, orange for AWS members, and green for sponsors.

Event Content: Sessions, Booths, and Special Events

The AWS Summit was a treasure trove of informative sessions, interactive booths, and unique special events that catered to a diverse audience. From tech-savvy professionals to industry newcomers, there was something for everyone.

Key Sessions

The event kicked off with the key sessions, which featured high-profile speakers such as CEOs and government officials sharing their vision for the future of cloud technology. With a runtime of 90 minutes, these sessions were offered in two languages and streamed online for those who couldn't attend in person. A DJ filled the venue with lively music, setting an energetic tone for the day ahead.

Case Study Sessions

Case study sessions provided real-world examples of how companies were using AWS to transform their businesses. These insightful presentations included in-depth discussions from company representatives and high-level architecture overviews, enabling attendees to understand the practical applications of AWS services.

AWS Sessions

These informative sessions, led by AWS employees, focused on the strengths and benefits of AWS services and how they could be used to solve various business challenges. I found these sessions particularly helpful in deepening my understanding of AWS. They also used a unique silent presentation format, which allowed attendees to listen to their chosen presentation using receivers. Below is photo of join stage and receiver.

Booths: AWS and Sponsor Booths

Booths were divided into two main types: AWS booths and sponsor booths. Each booth provided an engaging and interactive experience that brought AWS services and partner solutions to life.

AWS Booths

At the AWS booths, I witnessed firsthand how AWS services were being used in specific sectors. I saw demonstrations of AWS Amplify being used to create an MVP and AWS QuickSight being used to quickly create a dashboard. The knowledgeable AWS employees were eager to answer any questions and even followed up with an email the next day if I wanted to learn more.

Sponsor booths showcased cutting-edge technology and services from various companies. This was an excellent opportunity to explore potential solutions for my company, discuss my requirements with industry experts, and even collect some fun swag!

Other AWS Booths: Special Experiences

In addition to the technology and information-related booths, AWS also presented some unique experiences that I would call "Special Booths."

The first one was AWS DeepRacer, where visitors could build a machine learning model and integrate it into a small autonomous car (I have no idea how that works either!). The car then raced around a track, competing for the fastest lap time. The winners received special merchandise as a reward for their achievement.

Another engaging experience was AWS Jam, a team-based game that involved solving puzzles and completing challenges related to AWS services. I had the opportunity to watch others participate, and it seemed like a fantastic opportunity to network with other attendees while having fun and learning about AWS in a hands-on environment.

Conclusion

AWS Summit Tokyo 2023 was a whirlwind of learning, networking, and inspiration. Whether you're a cloud enthusiast, an AWS expert, or exploring potential solutions for your company, attending an AWS Summit is a must. The event offers a diverse range of sessions, booths, and special events, ensuring that there's something for everyone. So, if you ever have the chance to attend an AWS Summit, don't hesitate—dive in and experience the future of cloud technology!