Cloud RunとLoad Balancer：機械学習デモウェブアプリの効率的なデプロイ方法

目次：

はじめに
前提条件
アーキテクチャ
MLのデモウェブアプリを開発し、デプロイするには？
- アプリの開発とデプロイ
- アプリのホスティングとルーティング
結論

はじめに

こんにちは、Machine Learning(ML) Product DevelopmentチームのRobbinsです。みんなが元気でいることを願っています！このブログでは、MLデモウェブアプリをデプロイする効率的な仕組みを紹介したいと思います。

機械学習(ML)デモウェブアプリは、モデルを紹介し、より多くの人々がアクセスできるようにする強力な方法です。このガイドでは、開発からデプロイまで、MLデモウェブアプリの開発とホスティングのプロセスを説明します。アプリの構築にはStreamlit、コンテナ化にはDocker、ホスティングにはGoogle Cloud Platform（GCP）などを使用します。

GCPのCloud RunとLoad Balancerを使います。MLデモウェブアプリは Cloud Run にデプロイされ、Load BalancerがServerless Network Endpoint Group (以降、SNEG と呼称) バックエンドとしてドメインまたは IP アドレスの下でアプリをホスティングします。この方法の付加的な利点は、それぞれのウェブページで複数のMLデモウェブアプリを単一のドメイン下でホストできることです。Load Balancerは、クライアントやユーザーからホストされたバックエンドへのインバウンド・トラフィックとアウトバウンド・トラフィックを効率的に調整します。

上記は少し専門的すぎるように見えるかもしれませんが、このブログでこのアプローチをステップバイステップで説明することで、この仕組みをより深く理解し、MLデモウェブアプリをデプロイできるようになり、その過程でMLデモプラットフォームを構築するのに役立つことでしょう。それでは始めましょう！

前提条件

ステップに入る前に、以下のツールとアカウントがセットアップされていることを確認してください：

注：このブログは、あなたがPythonと機械学習の基本的な知識を持っていることを前提としています。

アーキテクチャ

このブログでは、以下のアーキテクチャについて説明し、実装することを目指します：

アーキテクチャの構成要素：

Artifact Registry: Artifact Registryは、コンテナイメージやその他のソフトウェアアーティファクトを保存・管理するための、安全でスケーラブルなリポジトリを提供するGoogle Cloudサービスです。
Cloud Run: Cloud RunはGoogle Cloud上のサーバーレスコンピュートプラットフォームで、スケーラブルかつコスト効率の高い方法でコンテナ化されたアプリを簡単にデプロイし管理することができます。
Load Balancer: Load Balancer は、管理、スケーラブル、高可用性の Google Cloud サービスで、インターネットトラフィックをアプリにインテリジェントに分散し、応答性と信頼性を確保します。
Identity-Aware Proxy (IAP): IAP は、Google Cloud のリソースとアプリに対してコンテキストを考慮したアクセス制御を提供する Google Cloud のセキュリティサービスで、ID とコンテキストに基づいてユーザーアクセスを簡単に管理し、保護することができます。
Domain Registrar: ドメインレジストラとは、ドメイン登録サービスを提供する企業や組織のことで、個人や企業がウェブサイトやオンラインプレゼンス用のインターネットドメイン名を購入・管理することを可能にします。

さて、必要な前提条件とこのアーキテクチャで使用されるコンポーネントについて説明しました。次のセクションでは、そのプロセスに深く潜ってみましょう。

MLのデモウェブアプリを開発し、デプロイするには？

手続き全体は、大きく分けて以下の2つのパートに分かれています:

アプリの開発とデプロイ。
アプリのホスティングとルーティング。

アプリの開発とデプロイ

Step 1: Streamlitを使ったMLデモウェブアプリの開発

StreamlitはオープンソースのPythonライブラリで、機械学習やデータサイエンス・プロジェクトのためのインタラクティブなWebアプリを最小限の労力で作成することができます。豊富なウェブ開発の知識がなくても、ユーザーフレンドリーなデータ駆動型アプリを構築できる優れた選択肢です。 Streamlitを初めてお使いになる方は、Streamlitスタートガイドをご覧ください。

Step 2: Poetry で依存関係をロック

MLデモウェブアプリを開発・デプロイする場合、異なる環境間での再現性を確保するために依存関係を効率的に管理することが極めて重要です。Poetryはこのプロセスを単純化するPython依存関係管理ツールです。プロジェクトの依存関係をロックするには Poetry を使います。ここでPoetryのチュートリアルをご覧ください。

Poetryを使うことで、依存関係の管理が簡単になるだけでなく、次のステップでDockerを使ってアプリをコンテナ化するのも簡単になります。次のステップでは、Dockerを使ってアプリをコンテナ化し、GCPにデプロイします。

Step 3: Dockerを使ったWebアプリのコンテナ化

Dockerによるコンテナ化は、MLデモウェブアプリの開発とホスティングのプロセスにおいて極めて重要なステップです。Dockerを使うことで、アプリとその依存関係をポータブルなコンテナにパッケージすることができ、様々な環境での一貫性を確保することができます。このステップでは、MLデモウェブアプリのコンテナ化を簡単に説明します。このDockerチュートリアルでは、Streamlitアプリ用のDockerfileの作成方法をご紹介します。

以下は、アプリをコンテナ化するためのステップです：

Dockerfileの作成： Dockerfileの作成は、アプリをコンテナ化するための第一歩です。DockerfileはDockerコンテナイメージを構築するためのスクリプトです。ベースイメージを指定し、環境を設定し、アプリコードをコピーし、コンテナの実行方法を定義します。

アプリの実行に使用するポートに関するおすすめは、ポートを8080に設定することです。これは、GCPのCloud Runがデフォルトでデプロイされたコンテナ・サービスに8080ポートを設定するためです。
Dockerイメージの構築： Dockerfileを作成したら、そこからDockerイメージをビルドします。ターミナルを開き、Dockerfileのあるディレクトリに移動し、以下のコマンドを実行します。このコマンドはカレントディレクトリ(.)をビルドコンテキストとして、ml-demo-app というDockerイメージをビルドします。

docker build -t ml-demo-app:latest .

Dockerコンテナの実行： Dockerイメージのビルドに成功したら、そこからDockerコンテナを実行することができます。このコマンドは ml-demo-app イメージからコンテナを起動し、コンテナ内のポート 8080 をホストマシンのポート 8080 にマッピングします。必要に応じてホストマシンのポート番号を置き換えてください。

docker run -p 8080:8080 ml-demo-app:latest

コンテナ化されたアプリのテスト：アプリコンテナを起動した状態で、ウェブブラウザを開き、http://localhost:8080（または指定したポート）に移動して、Dockerコンテナ内で動作するMLデモウェブアプリをテストしてください。期待通りに動作することを確認してください。

Step 4: DockerイメージをGCPの Artifact Registry にプッシュします

GCPはArtifact Registryという強力なサービスを提供しており、Dockerコンテナイメージを安全に保存・管理することができます。デプロイ時に簡単にアクセスできるように、DockerイメージをArtifact Registryにプッシュする方法をご紹介します。このステップでは、MLデモウェブアプリを含むDockerイメージをGCPのArtifact Registryにプッシュする手順を説明します。

先に進む前に、以下のことを確認してください：

GCPのアカウントとプロジェクトのセットアップ。
Artifact RegistryにプッシュしたいDockerイメージ。これは、Step 3で作成したDockerイメージである必要があります。

以下は、コンテナをArtifact Registryにプッシュする手順です：

Google Cloudで認証します： Artifact Registryを含むGCPサービスとやり取りするには、ローカル環境を認証する必要があります。以下のコマンドを実行し、指示に従ってください：

gcloud auth login

GCP認証用にDockerを設定します： DockerイメージをGCPのArtifact Registryにプッシュする前に、GCPアカウントの認証情報を使用するようにDockerを設定します。以下のコマンドを実行して、GCPアカウントでDockerを認証します。このコマンドは、コンテナレジストリとやり取りする際にGCP認証情報を使用するようにDockerを設定します。

gcloud auth configure-docker

Dockerイメージにタグを付けます： Dockerイメージをプッシュする前に、レジストリの場所とイメージ名をタグ付けする必要があります。この手順では、Artifact Registryに存在するリポジトリを使用することを想定しています。リポジトリがまだ作成されていない場合は、Artifact Registryに移動して作成します。[LOCATION]、[PROJECT-ID]、[REPOSITORY]、[IMAGE-NAME]を適切な値に置き換えてください：

docker tag ml-demo-app:latest [LOCATION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY]/[IMAGE-NAME]:latest

Docker ImageをArtifact Registryにプッシュします： Dockerイメージに正しくタグを付けたら、GCPのArtifact Registryにプッシュします。このコマンドはDockerイメージをArtifact Registryにアップロードし、GCPにデプロイできるようにします。

docker push [LOCATION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY]/[IMAGE-NAME]:latest

Artifactレジストリでイメージを確認します： DockerイメージがArtifact Registryに正常にプッシュされたことを確認するには、Google Cloud Consoleに移動し、メニューから「Artifact Registry」を選択します。そこに、あなたのイメージが表示されているはずです。

MLデモウェブアプリを含むDockerイメージをGCPのArtifact Registryにプッシュすることに成功しました。このステップにより、イメージが安全に保存され、GCPにデプロイできるようになります。

Step 5: Google Cloud RunへのDockerイメージのデプロイ

Google Cloud Runは、基盤となるインフラを管理することなくコンテナ化されたアプリを実行できるサーバーレスコンピュートプラットフォームです。このCloud Runクイックスタートに従って、MLデモウェブアプリをデプロイしてください。このステップでは、MLデモウェブアプリを含むDockerイメージをGoogle Cloud Runにデプロイする手順を説明します。

先に進む前に、以下のことを確認してください：

デプロイしたいDockerイメージ。これは、Step 4でGCPのArtifact RegistryにプッシュしたDockerイメージである必要があります。
Google Cloud SDK (gcloud)がローカルマシンにインストールされていること。まだインストールしていない場合は、こちらの手順に従ってインストールしてください。

以下の手順に従って、DockerイメージをGoogle Cloud Runにデプロイしてください：

GCP Project IDを設定します： [PROJECT-ID]は実際のGCPプロジェクトIDに置き換えてください。

gcloud config set project [PROJECT-ID]

Dockerイメージをデプロイします：以下のコマンドを実行して、DockerイメージをCloud Runにデプロイします。ここで説明するコマンドは単純なデプロイコマンドですが、サービスに対してより多くの設定を行う必要がある場合は、ドキュメントを参照してください。[SERVICE-NAME]`はサービスのユニークな名前に置き換えてください。

gcloud run deploy [SERVICE-NAME] --image [LOCATION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY]/[IMAGE-NAME]:latest --platform managed

デプロイ...： Google Cloud Runがコンテナ化したMLデモウェブアプリをデプロイします。これには数分かかります。
デプロイされたアプリにアクセスします：デプロイが完了すると、MLデモウェブアプリにアクセスできるURLが発行されます。以下のようになります： https://[SERVICE-NAME]-[HASH].a.run.app

おめでとうございます！MLデモウェブアプリを含むDockerイメージがGoogle Cloud Runにデプロイされました。アプリはサーバレス環境で実行され、ユーザは上記のURLからアクセスできます。

アプリのホスティングとルーティング

Step 6: Domain または IP アドレスの登録

ユーザーフレンドリーな方法でMLデモウェブアプリにアクセスできるようにするには、ドメイン名を登録するか、固定IPアドレスを取得します。このステップにより、ユーザーは覚えやすく使いやすいURLで機械学習アプリにアクセスできるようになります。ドメイン名は、1つのフードの下で複数のMLデモウェブアプリをホストしようとしているときに便利です。

Domain Resistrar（ドメイン登録サービスを提供する会社）を選択します。人気のあるDomain Resistrarには以下があります：

このステップは人によって大きく異なる可能性があるため、ほとんど説明せずに抽象化しています。ドメイン名を登録したり、固定IPアドレスを取得することで、ユーザがMLのデモウェブアプリにアクセスするためのユーザフレンドリな方法を提供します。ユーザーは、複雑なURLや変化するURLに依存する代わりに、ドメイン名（例：www.your-ml-app.com）や固定IPアドレス（例：123.45.67.89）を使ってアプリにアクセスすることができます。このステップにより、MLデモウェブアプリのアクセシビリティと専門性が向上します。

Step 7: External HTTPS Load Balancerのセットアップと設定

外部のHTTPS Load Balancerは、Google Cloud RunでホストされているMLデモウェブアプリへのトラフィックを安全にルーティングするために不可欠です。HTTPS ロードバランサーは、アプリが HTTPS 経由でアクセス可能であることを保証し、ユーザーインタラクションの暗号化とセキュリティを提供します。GCPでExternal HTTPSロードバランサーを設定するための包括的なガイドです。このステップでは、GCPでの外部HTTPSロードバランサーの設定と構成について説明します。

以下の手順に従って、GCPで外部HTTPS Load Balancerを設定および構成してください：

Cloud Runアプリケーション用の外部アプリケーションロードバランサーアーキテクチャ

Google Cloud Console の Load Balancer に移動します： GCP アカウントにログインし、Google Cloud Console を開きます。左側のナビゲーションメニューから、"Networking" > "Load Balancing" に移動します。
External HTTPS Load Balancerを作成します： ロードバランサーの作成」ボタンをクリックして、ロードバランサーを新規作成します。ロードバランサーの種類として「HTTP(S) Load Balancing」を選択します。
Frontend Configuration：
- Protocol: Protocol として "HTTPS" を選択します。
- IP Address: Step 6で取得した固定IPアドレスを選択するか、新規作成する場合は「IPアドレスの作成」を選択します。
- Port: HTTPSポート（通常は443）を設定します。
- Certificate: ドメインのSSL証明書を設定します。すでに証明書がない場合は、ドメイン用に新しい証明書を作成します。Googleが管理する証明書を作成すると、手間がかかりません。証明書が作成されたら、作成された証明書を選択し、SSLポリシー＞「GCP default」、QUIC negotiation＞「Automatic (default)」に設定します。
Backend Configuration:
- Backend Service: 新しいBackend Serviceを作成し、サービスに適切な名前を割り当てます。
- Backend Type: 私たちのMLデモウェブアプリはCloud Runサービスであり、Cloud Runサービスはサーバーレスサービスなので、バックエンドのタイプは[Serverless network endpoint group]として設定する必要があります。
- Serverless Network Endpoint Groups [SNEG]: ドロップダウンリストからSNEGを選択します。希望するSNEGがまだ作成されていない場合は、"CREATE SERVERLESS NETWORK ENDPOINT GROUP "をクリックし、Step 5で導入したCloud Runサービスの必要な詳細を入力してください。最後に "CREATE "ボタンをクリックしてバックエンドサービスを作成します。
Routing Rules:
- ここで、バックエンドにアクセスできるように、パスルールを記述する必要があります。
- Advance host and path rule "を選択します。
- (Default) Host and path rule for any unmatched "セクションで、"Route traffic to a single backend "を選択し、作成したバックエンドサービスを選択します。
- 上記ステップの後、「ADD HOST AND PATH RULE」をクリックします。「Hosts」の項目で、Step 6で作成したドメイン名を入力します。

# Path matcher (matches, actions and services) "項目に、
# 以下のyamlコードスニペットを入力します：
defaultService: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]
name: path-matcher-1
pathRules:
- paths: 
  - /* 
  service: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]  
  routeAction:   
    urlRewrite:     
      pathPrefixRewrite: /

# 同じホストにさらにバックエンド・サービスを追加する場合は、
# 上記のyamlスニペットに続けて以下のパス・ルールを追加します：
- paths: 
  - /* 
  service: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]  
  routeAction:   
    urlRewrite:     
      pathPrefixRewrite: /

作成したロードバランサーの設定を "Review and finalize "し、ロードバランサーをデプロイするために "CREATE "をクリックします。

Step 8: デプロイメントプロセスの自動化

デプロイメントプロセスを自動化することで、MLデモウェブアプリをホストするためのセットアップを簡単に複製することができ、効率的で再現性のあるデプロイメントが可能になります。このステップでは、一貫した構成で ML デモ Web アプリをデプロイする方法について説明します。

インフラストラクチャをセットアップするために必要なそれぞれのgcloudコマンドを連続的に実行するpythonスクリプトを書くことによって自動化を確立する方法について説明します。subprocessと呼ばれるライブラリの助けを借りて、pythonスクリプトを使用して作成することができます。これは、Step 7で構築されたロードバランサにMLデモウェブアプリを設定するために必要ないくつかのgcloudコマンドを連続的に実行するのに役立ちます。

なぜ自動化する必要があるのですか？自動化の目的は何ですか？自動化は、複数のMLデモウェブアプリを同じドメインアドレスで立ち上げようと計画している方にとって非常に有益です。主な目的は、MLデモウェブアプリのデプロイを可能な限り便利かつ迅速に行うことです。これにより、連続するMLデモウェブアプリを簡単に、手間なく、素早くデプロイすることができます。自動化は以下のステップで構築できます（ステップの流れには、関連するgcloudコマンドが含まれており、また、アプリがサービスとしてクラウドRunにデプロイ済みであることを前提としています）：

1. Serverless NEGを作成し、Cloud Runサービスを追加します

このステップでは、ネットワークエンドポイントグループを作成することで、SNEGに目的のCloud Runサービスを追加します。

必要な詳細は以下の通りです：

SNEG Name (適当な名前をつけてください)
Region (おすすめ: クラウドランサービスと同じにすることも可能です。)
Type of NEG (私たちの場合は "serverless "です)
Cloud Run Service ID (デプロイされたCloud Run Serviceの名前)

gcloud compute network-endpoint-groups create [SERVERLESS-NEG-NAME] \             
       --region=[CLOUD_RUN_SERVICE_REGION] \       
       --network-endpoint-type=serverless  \       
       --cloud-run-service=[CLOUD_RUN_SERVICE_ID]

2. Backend Serviceを作成します

このステップでは、SNEGバックエンドを迅速かつ安全にホストし、実行するために、特定の設定ステップを構成してバックエンドサービスを作成します。

必要な詳細は以下の通りです：

Backend Service Name (適当な名前をつけてください)
Load Balancing Scheme (構築した Load Balancer の名前)
Protocol (私たちの場合は "HTTPS" です。)
Port Name (私たちの場合は "HTTP" です。)
IAP
バックエンドのIAPを有効にするには、他に2つのgcloudコマンドを処理する必要があります。1つ目はOAuthクライアントの詳細を作成し、2つ目のgcloudコマンドは新しくデプロイされたCloud Runサービスを呼び出して認証リクエストを受け付けます。

1. Create an OAuth client：  
gcloud iap oauth-clients create [BRAND-ID] --display_name=[USER-FRIENDLY-NAME]

2. Cloud Run Serviceを開始します：
gcloud run services add-iam-policy-binding [CLOUD-SERVICE-NAME] \   
       --member=[SERVICEACCOUNT-FOR-INVOKING-CLOUDRUNSERVICE] \ 
       --role=[ROLE-FOR-SERVICE-ACCOUNT] \   
       --region=[REGION-OF-THE-CLOUD-RUN-SERVICE]

Logging
Global

gcloud compute backend-services create [BACKEND-SERVICE-NAME] \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --protocol=HTTPS \
       --port-name=http \
       --iap=enabled,oauth2-client-id=[OAUTH-CLIENT-ID],oauth2-client-secret=[OAUTH-CLIENT-SECRET] \
       --enable-logging \
       --global

3. 作成したServerless NEGを新しく作成したbackend serviceに追加します

このステップでは、作成したSNEG backend(ステップ1で作成)をbackend service(ステップ2で作成)に追加します。

必要な詳細は以下の通りです：

Backend Service Name (作成されたbackend service の名前）
Global
Network Endpoint Group Name (SNEGのName)
Network Endpoint Group Region (SNEGのRegion)

gcloud compute backend-services add-backend BACKEND-SERVICE-NAME \
       --global \
       --network-endpoint-group=SERVERLESS-NEG-NAME \
       --network-endpoint-group-region=asia-northeast1

4. URLマップを使用して転送ルールにbackendsを追加します

このステップでは、ロードバランサーがリクエストされたクライアントリクエストをターゲットのバックエンドサービスにルーティングするためのルートを設定します。残念ながら、このステップを実行する直接的なgcloudコマンドは存在しません。したがって、このアクションを達成するために間接的なアプローチが作成されます。
間接法は主に3つのステップで構成されています：

まず、既存の Load Balancer 設定スクリプトを .json か .yaml 形式で取得する必要があります。これを取得するには、以下のコマンドを実行します。

gcloud compute url-maps describe NAME-OF-THE-LOADBALANCER \
       --format=json > USER-PROVIDED-NAME-FOR-CONFIG-FILE.json

次に、クライアントをバックエンドサービスにルーティングするために、取得した .json 設定スクリプトにルートパスを手動で追加する必要があります。このプロセスは、「Step 7: External HTTPS Load Balancerのセットアップと設定」の「ルーティングルール」のセクションで簡単に説明しました。取得した.jsonファイルのうち、興味のある部分は以下のとおりです。

defaultService: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]
name: path-matcher-1
pathRules:
- paths: 
  - /* 
  service: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]  
  routeAction:   
    urlRewrite:     
      pathPrefixRewrite: /

新しく追加されたCloud Runサービスの新しいパスルールを追加した後の更新されたスニペットは以下のようになります：

defaultService: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]
name: path-matcher-1
pathRules:
- paths:  
  - /*  
  service: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]   
  routeAction:      
    urlRewrite:          
      pathPrefixRewrite: /
- paths:  
  - /*  
  service: projects/[PROJECT-ID]/global/backendServices/[BACKEND-SERVICE-NAME]   
  routeAction:      
    urlRewrite:          
      pathPrefixRewrite: /

緑色のコードスニペットは、新しく追加されたCloud Runサービスへのパスルールになります。
正しいパスルールでルートが構成されると、擬似アーキテクチャは次のようになります：

最後に、.json ファイルを Load Balancer にインポートする必要があります。この操作により、既存のロードバランサが変更された設定に再設定されます。インポートコマンドは以下のようになります：

gcloud compute url-maps import NAME-OF-THE-LOADBALANCER
       --source=NAME-OF-THE-CONFIG-FILE.json

以上の手順で、ロードバランサーのアーキテクチャが完成し、新しく追加された MLデモウェブアプリのホスティングに成功しました。最終的なアーキテクチャはこのようになります：

5. IAPで "Add principal "と "Assign role to backend service "を選択します

これが LB 構成の設定に関する最後のステップです。セキュアアクセスを許可するためにバックエンドサービスでIAP（Identity-Aware Proxy）を有効にしているため、対象のクライアントをプリンシパルとして追加し、[IAP-secured Web App User]というロールを割り当てないと、クライアントはウェブアプリにアクセスできなくなります。
必要な詳細は以下の通りです：

Backend Service Name (作成されたバックエンド・サービスの名前）
Principal

バインディングを追加する principal は、user|group|serviceAccount:email または domain:domain の形式でなければなりません。例：user:test-user@gmail.com、group:admins@example.com、 serviceAccount:test123@example.domain.com または domain:example.domain.com。 Role (Webアプリを使用する場合、Roleは[ IAP-secured Web App User ]、技術的には "roles/iap.httpsResourceAccessor "となります)

gcloud iap web add-iam-policy-binding \
       --resource-type=SERVICE-TYPE \
       --service=BACKEND-SERVICE-NAME \
       --member=PRINCIPAL-DETAILS \
       --role=ROLE-FOR-THE-PRINCIPAL

上記のステップとgcloudコマンドの引数は、要件に応じて変更することができます。gcloudコマンドに関するより深い洞察を得るには、googleでコマンド自体を検索し、GCPのドキュメントリンクに自分自身を導いてください。

おめでとうございます！新しいCloud Run Serviceを追加するために既存のLoad Balancerを自動的に設定する方法について、ワークフローの知識を習得しました。

結論

この包括的なガイドでは、機械学習（ML）のデモWebアプリをシームレスに開発し、ホストできるようにします。アプリ作成のためのStreamlitと依存関係管理のためのPoetryに始まり、私たちは強固な基盤を確保しました。Dockerコンテナ化とGoogle Cloud PlatformのArtifact Registryは、安全で再現可能なデプロイメントを保証します。

Google Cloud Runの費用対効果と拡張性の高さにより、効率的かつ安心してアプリケーションをホストできます。さらに、きめ細かなアクセス制御とセキュアなデプロイの実践により、セキュリティも強化されます。これらはすべてセキュリティを強化するだけでなく、特にデプロイの簡素化と自動化によって、卓越した開発者エクスペリエンスを優先します。

これらの強力なツールとプラクティスがあれば、MLイノベーションを創造し、世界と共有する旅に出る準備は万端です。

アンドパッドのデータ部では、「幸せを築く人を、幸せに。」というミッションの実現のため、MLOpsエンジニアを募集しております。

現在はアンドパッドのML活用の黎明期です。今後、機械学習をプロダクトに組み込む案件は増えていきます。また継続学習のために基盤を作り込んでいきたいとも思っています。MLOpsを経験がない方でも、得意分野を活かして課題を解決できる人を募集しているので、我こそはという人は、是非ご応募ください。

hrmos.co

コーディングとイノベーションをお楽しみください！