3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【実体験】技術導入のお話 - リアルな現場で経験したこと

Last updated at Posted at 2024-11-30

始めに

お久しぶりです、るんるんです。

今回は、私のリアルな現場での体験記になります。
その経験からの自己分析を行っているので、もしかしたら現場の肌感を知れるかもしれません(?)

いいね貰えると嬉しいです!🥰

こちらにも様々な記事を公開しています。ぜひご覧ください!!

プロジェクトの概要・背景

今回アサインされたプロジェクトは以下のようなもの

  • 新規開発
  • 新製品は並び替え等が頻発する
  • 既存製品では NoSQL の Datastore(Firestore) を使用していましたが、流石に今回の要件とは合わない
  • ということで、RDB でフルマネージドな AlloyDB for PostgreSQL を使用することになった。

このような感じだったが、以下の課題があった。

  1. 導入実績ないけど、うちは本当に RDB 使用できるの?
  2. AlloyDB の記事少ないけど、本当に使えるの?
  3. アーキテクチャとかどうするの?

などなど、分からないことだらけでした。

そこで「るんるん君、調査よろしく!」と言われ、「辞めさせて貰います...」

とはならず、「Big Chance!!!」 といった感じで、晴れて会社に新技術を導入するタスクを貰ったのです。

振り返り

ではここからが本題です。
新技術導入の中で、経験・感じたことを自己分析してみます。

成果と影響

成果としては以下

  • 以下のプロダクトを導入した
    • RDB: AlloyDB
    • ネットワーク: 共通VPC
    • セキュリティ: Secret Manager
    • CI: プライベートプール(Cloud Build)

影響は以下

  • 会社として初めて RDB の導入となるため、開発の可能性を広げた
  • 共通VPCを用いることで、コストを抑えることができた
  • Secret Manager を使用することで、パスワードをクラウド上で保存しハードコードなどで管理せずに済む
  • プライベートプールを導入することでデプロイ環境で、マイグレーションができるようになった

役割と貢献

役割としては

実験、導入実験、導入

これら全て自分で行った。

上司の方1名が管理者兼レビュワーで、実験に必要なものがあれば許可を得たり、ある程度アウトプットできたら見せたりしていた。

先輩1名が相談役として、困ったら助けてくれた。ありがとうございます。

技術的なチャレンジ

アーキテクチャを考えたこと

当初は開発環境(デプロイされた開発者が検証で使用する環境)ごとに AlloyDB クラスターを立てる予定だったが、コストが多大にかかる。

AlloyDB 専用のプロジェクトを作成し、共有VPC を用いて開発環境をサービスプロジェクトとして接続するような構成を考え、それを実行。

新しい Google Cloud プロダクトを導入したこと

AlloyDB が使用できるのかどうかの実験から行い、今回の要件に合うかの調査、導入することで既存製品に問題が起こらないかの確認など、全て行う。

共有VPC に関しても導入実績はなく、使用方法などをドキュメントを読みながら導入した。

また既存製品では Secret Manager を使用していなかったが、この際に導入し、DB 情報のハードコードを避けることに成功した。

Cloud Build から AlloyDB インスタンスに触れられるようにするため、プライベートプールを導入。こうすることで、Cloud Build 経由でデプロイ環境での DB マイグレーションが可能になる。

学びと成長

1人で Google Cloud のプロダクトを現場に導入できたこと。

またアーキテクチャを検討して、形にできたこと。

反省点

全体のスケジュールを決めることができず、ズルズルと後ろにズレ込んでしまった。

技術的に分からないことが多く、次から次へと課題が出てきていた。これ自体はしょうがないが、その時その時でリスケジュールせず愚直に取り組んでしまったことが問題。

上司に逐一どれくらいで終わりそうなのかを伝えることができておらず、外から見ていると「いつ終わるのだろう?」と疑問に感じさせてしまったのが今回の最大反省点。

困難だったこと

IAM

Google Cloud の権限周りに大苦戦しました。やっぱり AWS とかでもクラウドの一番難しい所だなぁとつくづくおもいます(人によると思いますけどw)。

ドキュメントの通りにやっても他に付与している権限が悪さをして上手くできないことや、プロジェクト構成が少し特殊だとどのサービスアカウントにどの権限を付与するのかなど。

度重なる実験を続け、最適解の権限を探索しました。 ← ここが一番時間がかかった。

楽しかったこと

やっぱり思い通りに動いた時

エンジニアをしていて堪らない瞬間だと思う。この感覚はいつまでも忘れたくない。

要件に合わせて構成を考えること

どのように実現できるかを、Google Cloud プロダクトのドキュメントを読みながら考える時間が楽しかった。
サッカーのポジションを考えているみたいで、楽しみながらできてよかった。

総括

如何だったでしょうか。

私が体験した現場を自己分析しながら振り返ってみました。
書いていて、時間を取って経験を振り返るのは非常に有意義だと感じました。
自分の趣向や強み弱みを改めて整理できて、次に活かせるような気がします。

今回は自己分析会でしたが、今度は「技術導入のいろは」的な記事も書こうと思っています。
乞うご期待!

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?