クラウドインフラ構築記

技術書典で購入しましたCloud Run書籍レビューです。

https://techbookfest.org/product/jQP5REJPx6pwMFEyx8QHPN

第1章 Cloud Runとは

ECS Fargate、App Runner、Cloud Runを比較して、Cloud Runの構成シンプルさ、スケールで軍配があがることが書かれている

ECS Fargateのターゲット追跡、ターゲットトラッキングについて書かれていますが、ターゲット追跡以外に、ステップスケーリングの手段もあります。ステップスケーリングだと、CPU負荷等が高まったときにタスク数を複数増やせますが、リクエストをうけつけるまで2〜3分のラグはあるので、スパイクには耐えられない。

第2章 とりあえず触ってみよう

Cloud Run serviceを、Google Cloudのコンソールから作る方法について書かれています。

第3章　Cloud Runによるシステムデザイン

Cloud Run serviceを、Google Cloudのコンソールから作る方法について書かれています。

第3章　Cloud Runによるシステムデザイン

すべてのCloud Runは、HTTPのエンドポイントを持ちます。

Cloud TaskもHTTP EndpointでCloud Run エンドポイントを叩くことも可

一例として、Google WorkflowはHTTP エンドポイントをつなぎ合わせてワークフローを構成できる。

https://cloud.google.com/blog/ja/products/serverless/announcing-direct-vpc-egress-for-cloud-run

認証を利用して、特定Service Accountからの通信のみ許可することも可能。

Serverless VPC Connectorの欠点を網羅した、Direct VPC EgressでVPC内部通信も可能。

 Direct VPC Egressのmax instanceのQuotaに注意。

Cloud SQLへの通信、Auth Proxyで、TLSで暗号化できるとはいえ、データベース側がパブリックIP付与するので、データベースパブリック露呈してくなければ、Direct VPC Egressでプライベート通信がいいように思えます。

第4章　プロダクションレディな設計

サービスアカウントキーが漏洩したら、セキュリティ事故に繋がる可能性があるので、キー発行はせず、github actionからGoogle Cloudのサービスにアクセス手段は、Workload identify Federationを推奨。

Cloud Deployは、Skaffoldをベースにしたツールなので、Cloud Runだけでなく、GKEへのデプロイにも対応しています。

Cloud loggingからLog SinkでCloud Storageにも送ることガ可能

Cloud Run serviceには、Compute Engineのデフォルトサービスアカウントが付与されますが、Cloud Run serviceごとにService Acccountを分けたほうがいい。AWSだと、IAM Roleに相当します。

コンテナセキュリティについては、Cloud Runだけでなく他のGoogle Cloudのコンテナサービスにも応用できると思います。

コンテナのCPU負荷は60%前後を維持するのがよさそうか。

Cloud DeployでCPU Brustなどを定義するには、annotationsを定義します。

https://cloud.google.com/run/docs/reference/yaml/v1

Cloud Runに関することが設計思想をふくめて、もりだくさんに書かれている書籍になります。

Anthropic Claude 3で、VertexAIやBedrockでも、Tool use (Function calling) つかえるようになりました、

https://docs.anthropic.com/en/docs/tool-use

 anthropic 0.28.0 

知りたい地区の天気をLLMに聞くと,locationを返して、Google GenCode API, openweathermap APIで現在の天気を返せるものがサクッと作れるようになりました。

from anthropic import AnthropicVertex
import requests
import json

def main():
    LOCATION = "us-central1"

    client = AnthropicVertex(region=LOCATION, project_id="xxxxxxx")
    response = client.messages.create(
        max_tokens=1024,
        tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather in a given location",
            "input_schema": {
            "type": "object",
            "properties": {
                "location": {
                "type": "string",
                "description": "The city and state, e.g. San Francisco, CA"
                }
            },
            "required": ["location"]
            }
        }
        ],
        messages=[{"role": "user","content": "柏の天気を教えて?"}],
        model="claude-3-haiku@20240307",
    )
    #  print(message)
    print(response.content[-1].input)

    payload = {'address': response.content[-1].input['location'], 'key': 'xxxxxxxxxxxxxxxx'}
    r = requests.get('https://maps.googleapis.com/maps/api/geocode/json', params=payload)
    # print(r.text['results'][0].geometry.location)
    d=json.loads(r.text)
    loc = d['results'][0]['geometry']['location']
    print(loc)
    # curl "https://api.openweathermap.org/data/3.0/onecall
    payload2 = {'lat': loc['lat'], 'lon': loc['lng'], 'lang': 'ja',  'appid': 'xxxxxxxxxxxxxxxxxx'}
    r2 = requests.get('https://api.openweathermap.org/data/3.0/onecall', params=payload2)
    d2 = json.loads(r2.text)
    print(d2['current']['weather'])
if __name__ == "__main__":
    main()

 {'location': '柏, 千葉'}
{'lat': 35.8675958, 'lng': 139.9757575}
[{'id': 500, 'main': 'Rain', 'description': '小雨', 'icon': '10d'}]

Search Engineering Tech Talk 2024 Spring #searchtechjp

https://search-tech.connpass.com/event/318126/

RAG改善からみたクエリ・ドキュメント理解とリランキング（FRAIM株式会社 水野多加雄 さん）

• 適切なドキュメントが根拠の上位にこない
• 同じキーワードが含まれる関係のないドキュメントがランクイン
• ユーザのクエリ意図に合った回答ができていない
• 用語定義を聞いているのに、関連のオペーレーション方法をかえしてしまう

の課題にたいして、どう改善するコトについての話

• SetFit
• Reranking
  • japanese-reranker　Cross-Encoder ベースモデルを日本語データセットJSQuAD等を用いて学習したもの

自然言語処理シリーズ-2 質問応答システム
質問応答タスクの分析が詰め込まれている。RAG改善のヒントになれそう
https://www.coronasha.co.jp/np/isbn/9784339027525/

文書登録時のチャンク、メタデータでドキュメントを絞り混むことが大事になる。

MongoDB Atlas Search, Vectorsearchの紹介、デモ　（MongoDB Singapore 林田千瑛 さん）

MongoDB Atlas Searchの特徴の説明がありました。

データベース、検索エンジンが分離されていると、同じデータだけどOLTPと検索を二重持ちデータ同期も複雑。パイプラインの開発も必要
レイテンシー劣化も起こる

MongoDB は、３つのシステムを１つに集約データの同期も必要ない
セキュリティも安全

MongoDBトは別にAtlas ノードがある
インデックス更新も同時にされり

20240320 MLOps勉強会 v39
https://www.youtube.com/live/x24JCS-XLGU?si=Bs7IgxIPcZiHeB-X&t=584

検索失敗率のモニタリングから改善まで　（株式会社ユーザベース 崔 井源 さん）

検索しても記事や動画を開かず離脱したものを検索失敗している
ここをモニタリング

プッシュ通知の文言で検索して失敗
既存は公開日順なので古い記事はなかなかでない

検索キーワードとして登録
通知されたコンテンツをアプリでみつけるのが難しいので検索ホーム
ラインキングロジックを改善
公開してからの経過日数、人気度合いをバランス良く考慮
重みを元に

Elasticsearchでトークンのオフセットがズレるバグについて　（株式会社LegalOn Technologies 神田 峻介 さん）

Lucene.Elasticserach Character Filer
ユニコード正規化するとトークンのオフセットに不正の値が入るバグ
頻繁におきるものではない

Doc Character Filter TokenizerToken Filterで登録される
ユニコード正規化、形態素解析、ストップワード除去など

start_offsert
end_offset

平成が人文字の一個のunicodeとして
空文字列として認識してしまう

CharFilter offsets correction is wonky　https://issues.apache.org/jira/browse/LUCENE-6595

対象外にしても、0.12%と検索結果への影響は少なそう

char_filter
unicode_set_filter　https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu-normalization.html

python で、モジュールをパッケージにするケースがあります。

• example
  • Dockerfile
  • setup.cfg
  • setup.py
  • example
    • __init__.py
  • main.py

まずは、モジュール化に必要なファイルの作成。setup.cfg、setup.py、__init__.py

モジュール化するスクリプトを作成。greetという関数で、Hello World!を出力するだけの簡単なものになります。

# -*- conding: utf8 -*-
__version__ = '0.0.1'
def greet():
print('Hello World!') 

setup 設定ファイル。

[metadata]
name = example
version = attr:example.__version__
author = Your Name
author_email = your-email@example.com
description = example is a example package
url = http://example.com/your/project/page
license = Apache License, Version 2.0
classifier =
Development Status :: 1 - Planning
Programming Language :: Python :: 3.6

[options]
zip_safe = False
packages = find:

pipは、setup.pyの記述でインストールを行うので、setup.pyを作成します。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from setuptools import setup

setup()

Dockerイメージで、モジュール化した関数を呼び出すpythonスクリプトを作成します。

import example

if __name__ == '__main__':
example.greet() 

最後に、Dockerfileを作成

FROM python:3.7.3

WORKDIR /app
COPY ./setup.py /app
COPY ./setup.cfg /app
RUN mkdir /app/example
COPY ./example/ /app/example/
RUN pip install -U .

COPY main.py /app
CMD ["python", "main.py"]

Dockerイメージをビルドを行い、

 docker build -t example .

イメージを実行すると、Hello World! が出力されれば成功です。

 docker run --rm -it example:latest 

Cloud Run full managed environemntsでも、glcoud コマンドなら、できる返信いただき、試してみました。

Traffic splitting is currently rolling out. Try `gcloud alpha run update-traffic` in the meantime.
Serverless VPC access is literally our highest priority item.

— Steren (@steren) February 2, 2020

( Cloud Run用Serverless VPCも優先度高く、対応中とのこと）

簡単な、python applicationで、試してみました。（チュートリアルにのっているものになります。）

import os

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
target = os.environ.get('TARGET', 'World')
return 'Hello  {}!\n'.format(target)

if __name__ == "__name__":
app.run(debug=True,host='0.0.0.0', port=int(os.environ.get('PORT', 8080))

FROM python:3.7

ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . .

RUN pip install Flask gunicorn

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 app:app

最初に、latestリビジョンでアップロードします。

 gcloud builds submit --tag gcr.io/xxxxxxxx/hellowrld 

Cloud Runへデプロイ

 gcloud beta run deploy --image gcr.io/cxxxxxxxx/hellowrld 

わかりやすいように、上記pythonスクリプトで、Helloのところを、Helllo 2として別リビジョンでアップロード

 gcloud builds submit --tag gcr.io/xxxxxxxx/hellowrld:canary 

再度、Cloud Runにデプロイ。

 gcloud beta run deploy --image gcr.io/xxxxxxxx/hellowrld:canary 

gcloud alpha run deploy　の、–no-traffic オプションで、次デプロイしたリビジョンへのトラフィックをこないように制御できるので、カナリアリリースようなことが、できそう。

リビジョンごとのトラフィックを下記コマンドで設定します。

 gcloud alpha run services update-traffic hellowrld --platform=managed --to-revisions=hellowrld-00003-hub=90,hellowrld-00001-kay=10 

マニュアルには、下記に記載。

https://cloud.google.com/sdk/gcloud/reference/alpha/run/services/update-traffic

コンソール上での表記

Billable container instance time でも割り振り状態は確認できます。

Visual Stdio Codeに、ptyhonをpyenvの仮想環境で使う場合、ちょっと設定が必要になります。

Google Cloud SDKが一部サブコマンド、python3に対応していないものがあるので、python 2.7を使う必要がある、かつ別で、python 3系を使いたい場合があるので、pyenvでpythonバージョンを切り替えて使っている。

pyenv -m venvはpython3になるので、ptyhon2系はこちらで、python仮想環境を作ります。

 pyenv -m virtualenv .env 

activateの確認。

 . .env/bin/activate 

VS Codeに、Cloud Codeのプラグインをインストールします。

https://cloud.google.com/code/docs/vscode/install?hl=en

Cloud Codeのプラグインをインストールできましたら、setting.jsonを編集します。

（pythonプラグインも必要です。）

python.pythonPathに、pyenv -m virtualenvでインストールしたpython pathを指定、ポイントになるのは、python.terminalactivateEnvironment をオンにすることです。

 {
"python.pythonPath": "/Users/hiruta/.venv/bin/python",
"python.venvPath": "~/.pvenv",
"python.terminal.activateEnvironment": true
}

Cloud Codeで、GKE Clusterを作成することができますが、すべてのオプションには対応していないようです。

Enable Istio、Enable Cloud Run for Anthosはありますが、preemptible VM、custom vpcは指定できるオプションは見つけられないようです。