ID:36365さん

概要

オンプレにあるAerospikeと呼ばれるKVSをGCPのBigTableに移行するための要件定義、API構築、インフラ構築、他事業部支援を行なった。

やったこと

セッションデータを管理するためにオンプレでAerospikeが動いていたが、スケールに耐えきれなくなったことや、保守が手間であることを理由に他事業部がクラウドへの移行を検討していた。

移行方法時代の立案から参画し、少しいびつな形でのダブルWriteを行うことになった。
というのもオンプレのAerospikeはネットワーク的に外部に公開することが出来ないため、GCP側に乗せるAPIからは書き込みや読み込みが不可能なためである。
そこでオンプレ側にAerospikeのデータを読み込むためのAPIの開発をGoを用いて1から行なった。

要件として1万RPS以上をさばけることが上げられていたので、クラウドにあるAPIからはgRPCを用いて通信を行うことで無駄なJsonのMarshal/Unmarshalを行わないようにした。

オンプレではシンプルにdocker-composeで運用することにした。
これはおおよそ半年程度しか必要のないAPIでk8sなど大掛かりなコントロールプレーンが必要ないと判断したためである。

また監視等はDataDogを自分で導入した。

また他事業部が作成したAPIのコードレビューに参加し、DDDライクなパッケージ構成を仕切れていなかった部分を教育した。
具体的には毎回無駄に外部API呼び出しのためのクライアントを生成していたのをDIを行えるような形に変換し、使い回せるような形にした。
またGraceful Shutdownが実現できていなかったのでそこを修正した。
テストもMockを使った形で実現できていなかったので、Mock用のオブジェクトの作成方法やテーブルドリブンテストの方法なども教育し、無事に各層の依存がないテストを作成することが可能な人材を作ることが出来た。

またそちらの手が回っていないということでGKEにDataDogによる監視を行うための設定やAlert設定等も行なった。

途中CircleCIからGithub Actionsへの移行が必要となったのでそれもすべて担当を行った。

また負荷試験の際に必要だったAPMの導入も行い、どこがボトルネックなのか可視化できるようになった。

概要

アルバイトを行っていた会社で地元のイベントのスマホアプリのバックエンドとして全ての機能をGolangを使って追加した。

制作

地元の大きなイベントのアプリで位置情報を使った情報提供を行うアプリを作成した。
一からの作成でMVCでの設計を行った。

こちらもGo + Goaという構成でスキーマ駆動の開発を行った。

位置情報のダミーデータが必要だったのでバッチでランダムに移動するBotの様なデータを挿入するCLIを作成した。

当日では逐次更新される情報をリアルタイムにPush通知で送信を行ったりと顧客目線での行動も行った。

概要

アルバイトを行っていた会社でキャンプメーカーのスマホアプリのバックエンドとして一機能をGolangを使って追加した。

##　制作

アプリのデザインから必要なエンドポイントの設計とデータベース設計を行いコーディング、テストまで全ての工程を担当した。

Go + Goaという構成でスキーマからRESTful APIを構築した。

実際にアプリサイドのエンジニアと協力して、必要な値の定義や、あえてきれいな設計を無視したデータ受け渡し等を行った。

データベースとのやり取りはORMを使わずにGoのsql packageをそのまま使って問い合わせを行った。

一部外部APIと接続しなければならない部分はきちんとMock APIを作成し、ローカルのみでの開発が行えるように整備を行った。

アプリサイドとはSwaggerを使ってやり取りを行い、適宜コミュニケーションを取りながら円滑に進めた。

運用の中でログローテーションの必要性が出てきたため、EC2に貯まるnginx周りのログデータをS3に定期的にアップロードするためのスクリプトも運用の中にとりいれた。

IaCとしてはCloudFormationが加入段階で使用されていたため、そこに追記する形で運用保守を行った。

概要

2週間でのハッカソンとして学習情報を共有するWebアプリをGolangとAWSを用いてサーバーサイドとして行った

制作

6人のチームで2週間ハッカソンを行った。
テックリード的な立ち位置で、サーバーサイドの設計から実装までを行った。
サーバーサイドのアーキテクチャとしてはレイヤードアーキテクチャを少し崩した形で設計した。
これはメンバー間のスキルの差があったため、レイヤードアーキテクチャで2週間で実装し切るのは難しいと判断したためである。
AWSの構成としてはFargateにAPIを載せ、S3でhostingするというよくある構成をとった。
これも2週間という少ない時間で最小限の動作を行うためである。
裏側ではDynamoDBとAuroraを併用して、特定データのみをDynamoDBに挿入するハイブリッドな構成をとった。
これは親子関係が激しく入れ替わるデータの性質上、RDBMSではデータ保管が難しくなるためである。