モード変更


    言語

モンスターラボの環境での実践と発見、未来への一歩

2024/09/20

モンスターラボにバックエンドエンジニアとして入社して1年が経過しました。 率直な振り返りを記事にしてみます。 実際にどのような経験ができるのか、それはどんな感じなのか、1つの視点として参考になれば幸いです。

フロントエンドエンジニアの Yuki Nakano さんの記事と共鳴するものがありますので、そちらも是非参照ください。

関連エントリ:モンスターラボの環境でTechLeadとして働くこと(2022年2月17日)

やったこと (What I Did)

クライアントワーク - 最初の半年

入社後は、次のような開発に関わることができました。

  1. インフラ基盤として Google Cloud をフル活用したシステムのスクラッチ開発

私が本格的にクラウドサービスプロバイダに触れたのはAWSが最初でしたが、Google Cloudの最初の利用サービスは、BigQueryとLookerです。 その時の開発体験が非常に良かったことから「もっとGoogle Cloudを使ってみたい」と思っており、入社後すぐにこの希望が叶うことになります。

このプロジェクトでは、AWS、Azureなどを使った開発も行われていたため、新領域としてAzureの世界も垣間見ることができる良い機会となりました。

クライアントワーク - 次の半年

後半では一転して、Azureに関して多くの経験値が得られる期間となりました。

  1. Azureを使った新たなWebアプリのモック開発
  2. Azureの運用下における、オンプレ→クラウド移行のためのPoCや、新規課題の調査・改善

前者は、モックに最適なサービス・プランを選定し、0から構築して機能開発・改善を進めます。 後者は、既にある仕組みが現状に至る背景の把握や、課題の深堀り、解決がそもそも必要なのか、妥協点はあるかという観点も視野に入れた活動です。

Azure Entra ID認証を正しく理解し、運用管理者と足並みをあわせて協同することも重要です。 Durable Functions について追加の Functions を書いたり、DBデータ移行ツールの機能を調査したり、App Service の中身(Kudu)を覗くこともあります。

目的や成熟度がそれぞれに異なるシステム開発に関わる中、興味をもって様々なニーズに対応していたら、Azureの知識も自然と溜まってきます。 取り組みの中で「点」として集めた知識が別の「点」と繋がり、時間を置いて、全く別の場面でも生きるということが起きました。

社内での多彩な活動

「Life at Monstarlab」ーーーバックエンドチームの週次ミーティングの資料に、おそらく何気なく書かれている言葉ですが、私はこのフレーズをとても気に入っています。

モンスターラボでの仕事は、クライアントワークだけでなく、ITエンジニアとしての多彩な活動が含まれることをシンプルに表現していると感じるからです。 RFPに対する提案、商談のほか、開発におけるスタンダード策定、Backend Tech Talk Session、生成AIの全社向け運用、輪読会など、さまざまな取り組みが存在します。

生成AIの全社向け運用では、Azure OpenAI活用チームのメンバーとして、日々のリクエストに応じたリソースの払い出しや、改善活動をしています。世の中のLLMプラットフォームの選択肢が複数ある中、会社としても活用を奨励しているので、まずは好きな生成AIを見つけて関わっていくアプローチもありと思います。

このブログ記事の章立て・構成検討においても、モンスターラボの有志が運用してくれている「Dify」で立てたGPT-4oと対話して仕上げています。

Backend Tech Talk Sessionは、自由にテーマが持ち寄られる会で、過去のセッションも後から視聴できます。

私の発表回では、Azureで認証を取り扱う機会が増えそうな気配を感じたことから 「Azure アプリケーションにおけるMicrosoft ID基盤を使った認証設置パターン 〜App Serviceを例に〜」というテーマを設定しました。

このように、個々人の興味分野や能力を発揮できそうな領域が何かと見つかる環境だと思います。 私自身に対しては、インプットとアウトプットのバランスを取る場として丁度良い具合にフィットしています。

わかったこと (What I Learned)

Google Cloudの Cloud Load Balancing、Cloud Run、Cloud Functions、Cloud Storage、Eventarc、Artifact Registry、Certificate Managerといった、巨大パブリッククラウドの強力なサービスの数々を組み合わせて実際にシステム構築することができるようになりました。

利用基盤が決定していたことから、その中でサービス選定や各種設計を進めれば良かったので、集中してサービス特性の理解に取り組むことができました。

最も興味深く見ていたのは以下のようなことです。

  • Cloud Functions(第2世代)とCloud Runの関係: 第2世代のCloud FunctionsはCloud Run上に配置されています。
  • Cloud Runの扱いやすさ: 事前設定を何もしなくても、容易にログにたどり着けるところが素晴らしいと思います。 Cloud Run ジョブも十分にシンプルで、実行時には設定をオーバーライド可能です。
  • Private Service Connect の仕組みと実装: 特に次の解説シリーズは繰り返し読み込みました。感謝。 初めての Private Service Connect #1 PSCってなに? 編
  • TerraformのTLS Providerと組み合わせて、Self-signed certificatesをスマートに扱える: つまり、以下のようなコードです。
# TLS Provider
# テスト用の自己署名証明書

resource "tls_private_key" "default" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "tls_self_signed_cert" "default" {
  private_key_pem = tls_private_key.default.private_key_pem

  # 証明書の有効期限
  validity_period_hours = 24 * 365

  # 証明書の有効期限の7days以内にTerraformが実行された場合、新しい証明書を生成
  early_renewal_hours = 24 * 7

  is_ca_certificate = true

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth"
  ]

  dns_names = ["*.${var.domain_name}"]

  subject {
    common_name  = "*.${var.domain_name}"
    organization = "ACME Examples, Inc"
  }
}
# Google Cloud provider

resource "google_compute_region_ssl_certificate" "default" {
  name_prefix = "my-certificate-"
  private_key = tls_private_key.default.private_key_pem

  # ここで証明書を指定できる
  certificate = tls_self_signed_cert.default.cert_pem

  region      = var.region
  lifecycle {
    create_before_destroy = true
  }
}

Azureでは以下のような気づきを得ました。

  • C#とAzureの恩恵: C#アプリは、(例えばnode.jsと比較して)Azureとの親和性が高そうです。なお、App Service自体もほとんどC#で開発されているとか。
  • Azure Entra IDの強さ: 強力な認証基盤ゆえに、選択肢として優位に立つケースが十分にあります。
  • App Serviceはその名の通りのコンセプトであること: 中でもAzure PortalからApp Serviceの内側であるKuduサイトにアクセスできるのが印象的です。 任意のexeを配置してcmdで実行したいといったシンプルな話だと、VMを準備しなくても、App Serviceで足りてしまうケースがありそうです。
  • サポートリクエストをオープンする際の、説明事項の大切さ: テキストだけでなく、ファイルを添付することで精細な情報を伝えることも可能なので、初めの手間を惜しまないことがスムーズなやりとりのコツです。 地味で基本的なことですが、忘れないようにしたいです。

次にやること (What I Will Do Next)

一旦置いておくこともあり

優先度の兼ね合いで、完遂しなかった課題もありました。

  • Google CloudのVMで、Windows 起動スクリプトをterraformで仕込むこと
  • C#でテストコードを作成すること(なお、モンスターラボでC#はレアです)
  • PowerBIのデータ前処理で、ちょっと複雑なMクエリを書くこと

これらはまた機会があれば取り組もう、というモチベーションにしておきます。

集中と発散で、より遠くへ

入社前は長く1つのプロダクトに関わっていたこともあり、ここ最近は「発散」をテーマにしていて、未経験の技術やサービス利用を実践できる環境が良いと思っていました。モダンという指向も重要です。

入社後は順調に実績解除を重ねており、これまでのところ大小さまざまな階段を、無理のないペースで上がることができています。

また、後ろ向きな意味でなく、純粋に「自分の伸びしろってまだあったんだ」ということも感じました。 今後も引き出しを増やして、設計・実装・様々な会話・アイデアにより高い価値が生まれるよう、楽しみながら活動し続けたいと思います。

以上、モンスターラボに興味を持つ方の参考になれば幸いです。

Article Photo by Patrick Tomasso

lifecareer

Author

Mika Mizuno

Mika Mizuno

Backend Engineer

interested in cloud architecture and refined products enthusiast.

その他おすすめ記事

2024/11/05

エンタープライズデータ基盤における dbt の活用戦略

近年、データ駆動型の意思決定が企業の競争力を左右する重要な要素となっており、大規模かつ複雑なデータ基盤の構築が不可欠となっています。この潮流の中で、dbt(data build tool)は、エンタープライズレベルのデータ変換とモデリングを効率化する強力なツールとして注目を集めています。 dbt は、SQL を使用してデータ変換を定義し、バージョン管理、テスト、ドキュメンテーションを統合的に行うことができるオープンソースツールです。特に以下の点で、エンタープライズデータ基盤の構築に大きな価値をもたらします...

Yoshiaki Sano

Yoshiaki Sano

Architecture

2024/11/04

データエンジニアリング初心者でも分かる!dbtの魅力と基本

データ駆動型ビジネスが当たり前となった今日、多くの企業がデータ分析の課題に直面しています。複雑な SQL クエリの管理、データの整合性確保、分析プロセスの再現性など、様々な問題が山積みです。そんな中で注目を集めているのが「dbt(data build tool)」です。 本記事では、データエンジニアリングの深い知識がなくても理解できるよう、dbt の基本と魅力について解説します。 dbt とは? dbt は、SQL を中心としたデータ変換ワークフローを管理するためのオープンソースツールです。従来の SQL...

Yoshiaki Sano

Yoshiaki Sano

Architecture

サービス開発実績会社情報
採用情報インサイトお問い合わせ
© 2022 Monstarlab
情報セキュリティ基本方針個人情報の取り扱いについて個人情報保護方針