こんにちは、ホシイです。 お知らせ… 残念ですが、今回の更新を持ちまして、このブログは更新を停止することになりました。 最近になって特に大きな変化があったというわけではないのですが、このまま継続していくための原動力もまた大きくなくなってきた… というのが理由です。 2022年5月にこのブログをはじめてから二年半ほど、週にひとつ、または隔週で記事を追加してきました。 あわせて 20名近くの社員から、おのおのの特徴が現れるようないろんな記事をお届けしました。 このブログはしばらくこのまま維持し、情報があまりに陳腐化してしまう前に公開を停止する予定です。 ハイライト ということで、見れなくなってしまう前に、これまでの記事の一部をご紹介したいと思います。この記事を読んでいただいた機会に、興味があるものを読んでいっていただけたら幸いです。 わたしも知らなかったような社員のキャラが立った記事がありました。 俺流！PEP668とうまくやっていく方法 [初級] ハマグリ式！ AWS Linux ログイン RTA ブログ公開を開始した頃からのトレンドもあり、また検索にもよくかかったようで、container (Docker, WSL) 関係の記事はよく読んでいただいていました。 Windows で Docker Desktop を使わない Docker 環境を構築する (WSL2) WSLのDNS設定をカスタムしたい（202203現在） 数は少なかったですが、実際のゲームタイトルに絡めた事例を紹介できました。 ストリーミングでクラウド体験版をリリースした話 お世話になっている会社様からご協力をいただいた記事もありました。 [レポート]AWS Summit Tokyo 2023 TiDBワークショップ『TiDBエキスパートへの道』に参加してきました！ CloudNative Days 福岡 2023 参加とオフィス訪問記 他にも様々な記事がありますので、タグ一覧 や 執筆者一覧 からお好みのものを探してみてください。 まとめ はじめた当初に予想していたよりも多くのかたに訪問いただき、社内外から反応をいただきました。 目的としていた、我々の業務を一部でも知ってもらうことに関してはある程度達成できたと考えています。 記事を読んでいただいた皆様、ほんとうにありがとうございました。 気軽にアウトプットができる場が無くなってしまうのは残念ですが、ここでなくても、またどこかでお会いできたら嬉しいです。 それではまた！ 👋

以前、GKE や Cloud Run で GPU を使う記事を書きました。 Cloud Run の記事では、実際には Vertex AI の Custom Jobs が良さそうということも書いています。 GPU を手軽に使うとき、他にもよいものがあるのか? をすこし見てみると、Batch もあることを思い出しました。あまり使ったことがなく、さらに GPU を使うとなると使い勝手はどうなのか? と気になったので、今回は実際に試してみたいと思います。 Batch にかかる費用 まずはいつもの重要なポイント、費用 をチェックします。クラウドリソースの料金について確認すると、どのようにすると低コストで運用できるかがわかるのはもちろんのこと、クラウドプロバイダー側でどのように使ってほしいかも透けて見えてきたりするので、しっかり確認しておくことをおすすめします。 Batch を使うことで追加の費用は必要ないそうですが、それを実行するのに消費するクラウドリソースぶんは課金されます。主に、compute (CPU/memory)、networking、disk などのおなじみの要素でしょう。処理に合わせて、必要最低限のものを選択するようにしていけばよさそうです。 ※ 費用も大きく変更されることがあります。使用される際には公式の情報を必ず確認してください。 実行方法を調べる 試行錯誤を繰り返すには、web console での操作より gcloud CLI を使用するのが便利です。Batch job を実行するかんたんなコマンドラインを書いてみましょう。 …と思ったのですが、command reference を見るに、なかなか複雑そうです。GCE VM の spec まで指定しようと思うと項目も多く、REST resource reference を見て書けなどと書かれていてなかなか敷居が高いです。 ということで今回は、web console の便利機能、「画面で設定している内容と同等の機能を実行する際のコマンドラインを取得できるボタン」を使ってみましょう。以下の図のこれ (赤矢印) ですね。 ちなみに上記は新しく job を作成する画面なのですが、project において Batch の API が enable されていないと、一部の項目選択でおかしな状態になってしまう (選択の操作ができない) ようです。こちら でも報告されているように、まだであれば API を enable しておきましょう。

Google Cloud の提供する Cloud Spanner (以下 Spanner) はスケーラブルなクラウドの database で、最近では graph database の機能が追加されたりなど、開発も盛んに行われています。 Google Cloud の database 製品では vector search の機能を持つものも多く、Big Query や Cloud SQL などその特性に合わせて選択することができます。Spanner に機能追加されたのもしばらく前だったと記憶していますが、試したことがなかったので今回はその使い勝手を試してみようと思います。 ※ ただし Vector functions は記事作成時点ではまだ preview 機能です。また、Spanner Standard では利用できず、Enterprise または Enterprise Plus が必要なようです。Spanner の Edition ごとの違いはこちら。 Spanner emulator を使います 1/10 instance から起動できるようになった とはいえ割とお金がかかるともよく言われる Spanner です。本番環境で使うには頼もしいことこの上ないんですけどね。というわけで、今回は Spanner の emulator を使用します。 この emulator、あまり気にしたことがなかったのですが こちら でソースが公開されており、見てみると (ハリボテではなく) 結構しっかりと実装されています。これだけメンテするのもなかなかたいへんそうです。ちなみにこの blog でもよくとりあげている Dev Container にも対応しており、 .devcontainer/devcontainer.json が用意されています。単に pre-built の image でかんたんに試したいときにはよいかもしれません。

RAG (Retrieval-Augmented Generation, 検索拡張生成) を使用した application を開発できる framework として、Firebase Genkit なるものがあると知りました。 Firebase は、認証や database など web app やモバイルゲームなどの開発に便利な様々な機能を提供している platform です。Firebase を利用することによってこういった機能の組み込みの敷居が下がり、また Google Cloud などの外部サービスとの連携による拡張も可能なので、小さくはじめて徐々にスケールしていく開発に威力を発揮します。 今回は、この Firebase Genkit を使った RAG application の開発体験がどのようなものなのか、公式 document Retrieval-augmented generation (RAG) に沿って見ていきましょう。 License Genkit の LICENSE は、Apache License 2.0 です。また、上記した document にあるコードもページ末尾の記述から同様に Apache License 2.0 と明記されています。 開発環境をつくる devcontainer の準備 いつもながら Visual Studio Code の Dev Container 機能を使用します。他の環境をご利用の方はお手数ですが、以下の構築手順を参考にして環境構築してください。 このブログでは他にも Dev Container に関する記事 があります。Dev Container って何? と思われたかたにもご覧いただけたら幸いです。 今回は Firebase で Node.

はじめに スクウェア・エニックスでSREをしている伊賀といいます。 今回PingCAP様主催のTiDBワークショップに参加してきたので、TiDBの概要と魅力についてお伝えしたいと思います！ PingCAP様の公式ページにもTiDBの紹介や事例等の掲載がありますので興味があれば是非！ https://pingcap.co.jp/ PingCAP様公式ホームページ https://pingcap.co.jp/event/workshop/ TiDBエキスパートへの道：実践的な知識とPingCAP認定のスキルアップワークショップ TiDBを一言で表すと「MySQLと高い互換性があり、オンラインでScale可能で、OLTPとOLAPも任せられるNewSQL」です。 もう少し言うとMySQLとの高い互換性による移行の容易性、高いScalabilityによる耐障害性、そしてコストメリットを得られる理想的なDatabaseだと考えています。 TiDBのアーキテクチャー 今回のワークショップではTiDBの基本的な構成要素をハンズオン形式で学ぶことができました。 TiDBは基本的にMySQL互換ですが、内部的には分散アーキテクチャーを採用しています。大きく分けるとSQL実行計画の生成と、SQL実行を担うTiDB Server、ストレージレイヤーであるTiKV、そしてOLAP系の処理を担うColumnar DatabaseのTiFlashが存在します。(Metadata管理を担うPD Serverの説明は割愛)。 この構成によって今までのDBでなかなか難しかったScalabilityを確保し、かつOLAP系の処理もアプリケーションが意識することなくTiKVとTiFlashが適切に分担して高速に処理し結果を返すというアーキテクチャになっています。 また、ストレージレイヤーを担うTiKVの実態はKey-Value型となっており、各ノードにデータを分散して持つため高い耐障害性とメンテナンス時も zero-downtimeでupgrade可能といった特徴を持っています。 ※図内に書かれている「リージョン」はデータ管理の単位であり、クラウドでよくある「地域」という意味ではありません TiDBは私達が抱える課題・辛さを解決できるか？ ゲーム特有のワークロードに対する悩みもありますが、それだけではなくDatabaseを運用していると誰もが遭遇する辛さを私も抱えています。 ピーク時にあわせたスペック設計による平常時のリソースの無駄 異なるワークロード、運用のためのReplicaが多い、これもリソースの無駄 OSやMySQL自体のバージョンアップや構成変更による計画停止 TiDBならその課題全部解決できます！(と私達は信じています！) 1.ピーク時にあわせたスペック設計による平常時のリソースの無駄 TiDBはオンラインでNodeのScale Out/In・Up/Downが可能です。アプリケーションの処理に影響を与えず可能です。適切にScaleさせるにはDBへの負荷が予測可能であるという前提ですが、ピーク時の負荷が平常時の100~1000倍になるようなワークロードのDBに対しては、これだけでかなりのコストメリットが出ると思います。 2.異なるワークロード、運用のためのReplicaが多い、これもリソースの無駄 次に2つめの辛さです。OLTP用、OLAP用、backup用、分析用、、と影響の分離や異なるワークロードに対してReplicaを用意し、急激にサーバー台数が増えていく状態を経験しています。一定のReplicaを利用したある程度の分離は安定運用のためには欠かせないのですが、基本的に増加していく一方で、必要に応じて統合していくというのはコストもかかるし減らして大丈夫かの試験なんてやってる暇ないですし、、、現実的にはとても難しいですよね。 TiDBでは1セットでいけます！ 3. OSやMySQL自体のバージョンアップによる構成変更による計画停止 TiDBはバージョンアップもオンラインでできちゃいます。分散アーキテクチャーだからこそできる、ローリングによるアップグレードですね。何よりそのシステムを使うユーザー、別システムに対してサービス利用不可の時間を低減することができ、ビジネスの機会損失を最小限にすることができると思います。toCであったり24✕365のシステムなら喉から手が出る特徴なのは勿論なのですが、停止可能なシステムにおいてもアップグレードの敷居がかなり低くなるので検討の余地はあると思っています。 どこにでもある課題ですがTiDBならまるっと解決できそう、、、、というのが今私達が考えていることです。 TiDBを使うために超えないといけない壁 ここまでTiDBを褒めちぎってきたわけですが、MySQLからTiDBに移行するときに壁がないわけではありません。恐らく、分散アーキテクチャによるパフォーマンスの問題が大きく立ちはだかると思っています。 例えば、よくあるテーブル設計としてAUTO INCREMENTを利用したPKを持つことはあるかと思います。しかし、そのままTiDBで利用した場合には前述のデータの持ち方に起因して、当該テーブルへの書き込みは特定リージョン(TiKVでのデータ管理単位)に負荷が偏る、すなわち書き込み時のHotspotを誘発しパフォーマンスが落ちるという特性もあったりします。 また、TiKV内部ではPK以外のIndexとテーブルデータに対して、KVレコードをそれぞれ別に持ちます。したがってパフォーマンスの観点では、Indexを経由することで読み取りコストが増えてしまわないように、PK以外のIndexを利用しないで済む設計をするほうが望ましい気がします。また、ストレージの観点ではIndexを極力利用しないほうが余計なKVレコードを持たないで済みます。 これらのことから、特にTiDB自体のアーキテクチャーを理解したうえでSQLの調整をしていったほうが良さそうという印象です。 予想するにスペックや台数でお茶を濁せる場面もあるとは思いますが、コスパよくTiDBを使っていくためには検証必須だと考えています。 ただ、TiDBに内包されているKey Visualizer機能があるようなのでこれを駆使して解決していくことになると考えていたり、今後大きな流れの1つになっていくと思われる分散系DBの細かいアーキテクチャーをキャッチアップするのは自分の価値を高められると前向きにも考えています。 まとめ TiDBを採用する壁はあるものの適切なSQL設計を行えば、高い可用性と耐障害性、並びに大きなコストメリットを得られる次世代のデータベースだと感じました。 まさしく『New SQL』だと考えています。 そしてワークショップに参加することで詳細な内部の技術的な解像度が高まり、もっと知りたい、検証してみたい！という気持ちになりました。

以前の記事 で、処理を実行している間だけ GPU を専有する (料金を支払う) ために、GKE Autopilot を使用する例を書きました。これにより、新しく job を実行するだけで自動で GPU が割り当てられ、処理が終われば開放される、スケーリングも柔軟… とよい点は多いものの、インフラの用意はじゃっかん手間であったり、cluster の維持費用 ($0.10/h = 月に一万円程度) がかかるなど、残念ながらお手軽とは言えません。 そんな折… Cloud Run に GPU support が追加された！ …けど なんと、お手軽の代名詞のような Cloud Run で NVIDIA GPU が使えるようになった ということで、preview の現状ではありますが、仕様を確認してみました。 結果、以下の制限が (わたしには特に) 厳しそうに感じました。 Cloud Run の CPU always allocated option が必須 (当然だが) CPU 割り当て中は GPU も割り当てされる (課金される) NVIDIA L4 GPU のみ (これはきっと拡大していく) ひとつめですでにオッなるほど！という絶妙な納得感がありますが、これだと GPU を使う application を job として「必要なときだけ実行する」用途には向かなさそうです。 Pricing によると Tier-1 region で NVIDIA L4 が $0.

Graph database を扱ってみた、前回 の続きです。 もともとは Spanner が graph database に対応 したというのを見たのが発端だったのですが、そこから Vertex AI samples > neo4j/graph_paysim (Jupyter Notebook) に入り、graph database に関しては見終わったものの、この例の後半にある Vertex AI を使用する部分には触れられなかったので、今回はそこを見てみましょう。という経緯です。 Spanner の graph database 機能には一切関係なくなっていますがまあいいでしょう！ サンプルコードが何をしているかを見る 前回記事で触れられなかった、Vertex AI samples > neo4j/graph_paysim (Jupyter Notebook) の後半で何をしているかを読んでみます。 Train and deploy a model with Vertex AI 前半で作成した train.csv を GCS に置く それを dataset とし、AutoML を使って train job を実行する。 prediction type は classification で target column は is_fraudster model を paysim-prediction-model として保存、deploy する Loading Data into Vertex AI Feature Store ここで Feature Store が登場。まだ存在しなければつくる。 GCS に置いた train.

Spanner が Graph database に対応 したというのを見て、では何ができるのか… とすこし考えていました。 わたし自身は IT エンジニアの区分であり数学の素養はからっきしなのですが、AI エンジニアやデータサイエンティストのお仕事はスムーズにサポートできるようにしておきたいと思っています。Graph database が必要な業務に対して迅速にサポートできるように、日頃から馴染んでおくことが大切に思いましたので、今回はその環境をつくって触ってみるところまでをやってみます。 Spanner が対応したとはいえ、emulator にその機能がついているかはパッとわからなかったので、他で世間一般によく使われていそうなものを探してみました。Spanner 自体は費用がかかることと、Spanner そのものの特徴も混ざってくるように感じられたので、今回は graph DB に特化した他のものを使ってみます。 以下あたりの情報がとっつきやすそうに感じられました。Google Cloud の記事ですが、すこし前のもので Neo4j という database を使用しています。 Neo4j と Google Cloud Vertex AI でよりスマートな AI 向けのグラフを使用する Vertex AI samples > neo4j/graph_paysim (Jupyter Notebook) Graph DB を体験するところまでなら、この手順に従って local に閉じて費用を気にせず実施できそうです。 上記 GitHub に置かれている Jupyter Notebook (.ipynb) の手順をなぞっていきますが、今回は local で手早く済ませるため Notebook ではなく python を直接使用します。 とりあえず環境をつくる いつもながら Visual Studio Code の Dev Container 機能を使用します。他の環境をご利用の方はお手数ですが、以下の構築手順を参考にして環境構築してください。

もはや最近は一日家で過ごしていると、人間よりも AI と会話しているほうが多い日もあるかもしれません。外に出るにも危険な日差しで、精神の健康を保つのに工夫が必要な日々と感じます 😓 さてかなり以前から映画などでは、人間をサポートする AI が膨大な知識と優れた判断力を使って素早く解決案を提示し、主人公を助けるというシーンをよく見ます。そこで主人公はその提案に対して「よし、それで頼む」とさらっと言うわけですが、AI が実行までしちゃうと主人公がいなくてもよくなってしまうので、映画では何かしら問題が起きて人間たちが活躍し、「やっぱり手動がいちばんや！」となるオチが多いです。 ともあれもし AI に実行までしてもらえるんなら、特に現実世界では、こんな楽なことは無いです。 日々会話している AI。会話で応答を得るだけでなく、実際に行動をする仕組みを追加することができます。今回はそれを試して映画の世界に一歩近づきましょう。 Vertex AI Function Calling Vertex AI には、AI の判断に基づいて (AI model の) 外部の機能を呼び出す機能があります。 Generative AI on Vertex AI > Function calling こちらに沿って試してみます。 事前準備 いつもながら Visual Studio Code の Dev Container 機能を使用します。他の環境をご利用の方はお手数ですが、以下の構築手順を参考にして環境構築してください。 このブログでは他にも Dev Container に関する記事 があります。Dev Container って何? と思われたかたにもご覧いただけたら幸いです。 host 側 Vertex AI の利用に必要な Google Cloud 認証は、host 側の application default authentictation を使用します。host 側で以下を行っておきます。(host 側に Cloud SDK の install が必要です)

ホシイです。 拡張性が高い Kubernetes。様々な機能・ソフトウェアが、Kubernetes が備える機能拡張の仕組みである operator や controller で提供されるのを見るようになりました。GitLab Operator のような複雑な application や、MySQL Operator のように database 機能を提供するものもあります。より単純な機能としては、Pod などを監視しつつ条件に応じて scaling や backup するなどの機能が考えられます。 Kubernetes の Operator pattern に説明されている Operators は、Kubernetes 自体に手をいれることなく controller や custom resource を使い、cluster での deploy や workload 管理を拡張するものとされています。 この強力な機能が活用できると非常に心強そうですが、何しろ敷居が高そうなのもたしかです。今日はその敷居を少しでも下げるため、custom controller の実装を体験してみたいと思います。 事前準備: Dev Container と kind controller を開発するにあたり、それを実行する Kubernetes cluster が必要です。ここでは、kind を使います。kind は Kubernetes 自体の開発にも使われているもので、軽量な Kubernetes cluster を実行できます。 もしすでに他の Kubernetes cluster 環境をお持ちであれば、そちらを利用することもできると思います。ご自身の環境に合わせてセットアップしてください。 今回は、開発環境構築に Visual Studio Code の Dev Container 機能を使用します。Dev Container は、container を使用して開発環境を構築する強力な機能です。開発環境構築をコード化して共有したり、開発環境を隔離してホストをきれいに保つことができます。このブログでは他にも Dev Container に関する記事 をいくつか書いているので、ぜひ見てみてください。

はじめに NewSQLとして注目を集めているTiDBについて、今回はそのサーバレスDBaaSであるTiDB Servelessを取り上げます。 TiDB Serverless は無償で利用開始でき従量課金であるという特徴の他に、AIを利用して自然言語からクエリを生成してくれる Chat2Query という機能があるので、これを試してみます。 環境構築 少しレガシーなゲームのデバッグ用環境のDB(MySQL5.7.x)から、データをTiDB Serverlessに突っ込んでChat2Queryを雑に扱う、というような検証を行いました。 まずTiDB Serverlessにデータを投入する必要があります。今回は、IaaS上で動いているMySQLを運用していれば珍しくないであろう、 mysqldump コマンドで取得されたデータ(DDL込み)を持ってきてS3に配置し、TiDB ServerlessのImportで読み取りました。しかし、残念ながらそうしたデータをImportは読んでくれません。 データを投入するには、Importが読める形式に合わせる必要があります。 Naming Conventions for Data Import Import CSV Files from Amazon S3 or GCS into TiDB Cloud データ加工を考えるのは少し面倒だな、と思っていたところ、PingCAPの方からTiDB用のツール群である tiup に含まれるdumpデータ取得ツール dumpling Dumpling Overview | PingCAP Docs を使えば問題無いというアドバイスをいただきました。 tiup dumpling の具体的な利用方法として、以下のようなコマンドを教えて貰っています。 tiup dumpling \ -u "dbuser" \ -p "******"" \ -P 4000 \ -h <host> \ -F 256MiB \ -o "<s3 Bucket>" \ --s3.

こんにちは、ホシイです 👋 Internet 越しの API 呼び出しがより一般的になったことや、何より public cloud での運用が増えた昨今、network の遅延や packet loss は日常的なものとして認識しておく必要があります。server application の開発でも、普段からそのような環境での動作で問題が発生しないか確認しておくことが重要でしょう。 Docker を使って低品質 network 環境を模倣する 今回は、network 遅延のような状況を検証しやすい環境を Docker を利用して構築してみます。 こちら を参考にさせていただきました。 上の記事でもすでに Docker Compose で実行できるようになっていますが、VS Code の Dev Container で動作すると network 通信を含むシステム開発に便利そうだなと思ったので、いくらか更新・最適化をしてみました。 また、今回の内容は環境に左右される度合いが大きいようなのでご注意ください。以下の環境で動作を確認しています。 macOS Sonoma + Docker Desktop Windows 11 Enterprise + Docker Desktop (WSL を使用しない・補足を参照) 構成と必要なフォルダ構成 Dev Container を利用するにあたり、以下のフォルダ構成をつくります。(VS Code + Dev Containers extension の導入を前提としています) ゼロからやるとすこしめんどうですが、つくるファイルは 3 つだけです。 workspace ├─ .devcontainer/ │ └─ client/ │ └─ Dockerfile │ ├─ compose.

こんにちは、ホシイです 👋 今回は、記事タイトルを見てもぱっとイメージしにくい話題です。ちょっと複雑で、うまく説明できるか自信がないですが、ひとつずつ順を追って書いてみます。 ちなみに (いつもそうですが) 記事の内容は弊社すべてのシステムで採用している技術・ポリシーではなく、ひとつの解決案としてお考えください。 外部 API 呼び出しをするサーバーでのよくある悩み web アプリケーションなどで、リクエストを受けたサーバーがさらに外部の API 呼び出しをすることってよくありますよね。そして、このインターネット時代、そういった API 呼び出しは失敗することもあればタイムアウトすることもよくあります。エラーが返ってきたならまだしも、うまくいったかどうかもわからない場合は、どうしたらいいでしょうか? 今回はここをスタート地点にして、どういった解決が考えられるかを見ていきます。 ちなみに今回の対象は、数百ミリ〜数秒かかるような処理で、比較的時間はかかるがひとつひとつの通信の確実性を重視するもの、典型的には「アプリ内通貨を差し引いてアイテムを得る」ようなものを想定しています。 サーバー通信といっても、より頻度が高く低レイテンシーを要求するリアルタイム性の高いもの (オンラインアクションゲーム等で使用されるもの) もありますが、そういった用途にはまったく別の仕組みが用いられますので、今回の記事では扱いません。 リトライと課題 API 呼び出しが失敗したとき、まず考えられるのはリトライです。network がいつも 100% 完全と言えない以上、リトライすること自体は必須でしょう。しかし、ここでいくつか問題があります。 API はほんとうに失敗したのか? タイムアウトしていた場合、実は結果が得られていないだけで、API の処理自体は成功しているかもしれない この場合、リトライすると、二回 (以上) 操作することになってしまわないか リトライするとして、回数とか間隔、契機・トリガー条件はどうしたらいいか 一般的な解決策として、処理の冪等性と exponential backoff があります。ひとつずつ見ていきます。 冪等な処理として実装する (idempotent にする) API などの機能を実装するとき、おなじ入力であれば複数回呼び出されても一回の実行と結果が変わらないようにします。たとえばあるユーザーのスコアに 300 を足す処理で、リトライしたからといって二回足して 600 になっちゃうとマズイです。 冪等でない処理 一回目) user_id 1000 のスコアに 300 を足す → { user_id: 1000, score: 300 } 二回目 (リトライ)) user_id 1000 のスコアに 300 を足す → { user_id: 1000, score: 600 } 冪等な処理

こんにちは、クラウドエンジニアのタケウチです。 スクウェア・エニックスに入社するまでは主にAWS環境での作業を業務としており、 初めて Google Cloud API について学習する機会があったので、 Compute Engine リソースの基本操作を Python ライブラリを利用して実施する場合についてまとめていきます。 主に Compute Engine リソースの基本操作を元に Python ライブラリを利用して初めて実施する方向けの情報になります。 セットアップ Python 自体の設定については今回は割愛しますが、私が実施した環境は wsl2 + ubuntu + pyenv + venv です。 またデフォルトの認証情報を設定するために、gcloud コマンドも別途セットアップして利用しました。 公式ドキュメントとしてPython環境のセットアップについても用意されているので、 Python 環境を最初から設定する場合は参考にすることもできます。 アプリケーションのデフォルト認証情報の設定 Google Cloud API を利用する場合にアプリケーションのデフォルトの認証情報を設定します。 今回については公式ドキュメントの通りにローカル開発環境用の認証情報を用意しました。 認証情報作成の gcloud コマンドを実行するとブラウザに遷移するので画面の指示通りに進めると デフォルトの認証情報が$HOME/.config/gcloud/application_default_credentials.jsonとして作成されました。 ライブラリのインストール 今回については基本的な google-cloud-compute に加えて google-auth をインストールして利用します。 具体的な利用方法については後述しますが google-auth は例外処理に利用します。 また依存関係によって他のライブラリも同時にインストールされ、今回はその中の google-api-core についても例外処理に利用します。 今回必要なライブラリを以下のようにインストールします。 pip install google-cloud-compute google-auth インスタンスの状態取得、起動、停止 認証情報、ライブラリの用意ができたら早速インスタンスの状態取得、起動、停止について見ていきます。 インスタンスの状態取得 今回は以下のフローで作成しました。 フィルターを紹介するためlistで取得するようにしていますが、 getというメソッドで単一のインスタンスを取得することも可能です。 認証情報を利用してInstancesClientを用意 必要な変数などを定義してListInstancesRequestを用意 用意したクライアントとリクエストを使用してインスタンスのリストを取得

はじめまして！インフラエンジニアのぺんぺんです。 今回は、直近で私の担当する案件で行った検証をノウハウとして残すという意味で以下についてお話させていただきたいと思います！ 『MySQL8.0でinnodb_buffer_pool_sizeをオンラインで縮小するときってどんな影響があるのでしょうか』 まず初めにこのパラメータを設定することによる利点ですが、innodb_buffer_pool_sizeを設定することで、InnoDBがアクセス時にテーブルやインデックスデータをメモリ内でキャッシュするための領域を確保できます。 これにより、ディスクI/Oの回数を減らしてデータベースのパフォーマンスを向上させることができます。 MySQLを使っている方は多いと思いますし、innodb_buffer_pool_sizeはチューニングの代表的なパラメータの1つだと認識しています。 とはいえ、オンラインで拡張することはあっても縮小するのは私も初めての機会でした。(縮小することでスロークエリの発生が増えてサービス影響が出る可能性があるため、メモリが足りないならスペックアップの判断をしがち) 今回はこのinnodb_buffer_pool_sizeの値が推奨値※の50%～75%を大きく超えて割り当てを行っていたことにより、メモリ不足を起こしてしまったので、推奨値に収まるように縮小するにあたり、影響を確認するために今回の検証を実施することとなりました。 ※推奨される innodb_buffer_pool_size 値は、システムメモリーの 50 から 75% 検証前の想定では、縮小に伴いdirty pagesのフラッシュが発生することでディスクI/Oが発生して一時的にパフォーマンスが低下するのでは？というくらいに考えていました。 検証詳細 検証環境 MySQLバージョン：8.0.34 構成：InnoDBCluster(シングルプライマリ) 実メモリ：256GB 事前準備 自作のwarmupスクリプトを実行し、事前に本番環境とpages_dataを揃えておきます。 検証方法 検証環境に対してsysbenchを使って700qpsの負荷をかけ続けている状態でdirty pagesが本番環境と同等になったことを確認したのち、「set global innodb_buffer_pool_size = 167,772,160」を実行(220Gb→160GB)し、縮小時の影響を確認しました。 検証結果 【19:28:32】にset globalを実行し、7つの確認ポイントとその前後の各種値を以下に記載します。 [1] innodb_buffer_pool_sizeの変更にかかった時間 変更自体は1秒未満で完了しています。[19:28:30] Variable_name Value innodb_buffer_pool_size 236223201280 [19:28:31] Variable_name Value innodb_buffer_pool_size 236223201280 [19:28:32] ★set global実行、リサイズ開始 Variable_name Value innodb_buffer_pool_size 171798691840 [19:28:33] Variable_name Value innodb_buffer_pool_size 171798691840 [19:28:34] Variable_name Value innodb_buffer_pool_size 171798691840 [2] innodb_buffer_pool_pages_dataの変更にかかった時間 innodb_buffer_pool_sizeと同様に、変更自体は1秒未満で完了しています。[19:28:30] Innodb_buffer_pool_pages_data 14409408 Innodb_buffer_pool_bytes_data 236083740672 [19:28:31] Innodb_buffer_pool_pages_data 14409408 Innodb_buffer_pool_bytes_data 236083740672 [19:28:32] ★set global実行、リサイズ開始 Innodb_buffer_pool_pages_data 14365499 Innodb_buffer_pool_bytes_data 235364335616 [19:28:33] Innodb_buffer_pool_pages_data 10687130 Innodb_buffer_pool_bytes_data 175097937920 [19:28:34] Innodb_buffer_pool_pages_data 10498607 Innodb_buffer_pool_bytes_data 172009177088 [3] innodb_buffer_poolのリサイズにかかる時間 リサイズがCompletedになるまで約20秒程かかっています。「Innodb_buffer_pool_resize_status」なんて値があるなんて初めて知りました。 ※オンラインバッファプールのサイズ変更の進行状況の監視

はじめに この記事を見つけたけど、後で見ようと思ったそこのあなた！ ぜひ下のボタンから、ハッシュタグ #ハマグリ式 でツイートしておきましょう！ こんにちハマグリ。貝藤らんまだぞ。 今回は AWS および Terraform の初級者向けに「ハマグリ式！ AWS の基本的なネットワークまとめ」をご紹介します！ 初級者って？ ハマグリ式では、下記のようにレベルを設定しています。 初級者：初めてクラウドサービスを利用する人で、基本的な操作（例：ファイルの保存や、サーバーの起動）をインターフェースを通じて行うことができます。また、シンプルなセキュリティルールの設定や、一部の問題のトラブルシューティングに対応できます。 中級者：より深い知識を持ち、コードを用いて操作を自動化したり、より複雑なタスク（例：自動でサーバーの数を増減させる）を行います。また、より高度な監視や、全体のシステム設計と実装について理解があります。 上級者：幅広く深い知識を持ち、大規模で複雑なシステムを設計、実装、維持する能力があります。最先端のテクノロジーを活用し、安全性、耐障害性、効率性を最大化するためのソリューションを提供します。 なお上記は ChatGPT による出力ですが、この記事でほかに生成 AI によって出力された文章はありません。ただし、記事のドラフトには生成 AI を利用しています。 ハマグリ式って？ 貝藤らんまが作成するブログ記事のブランド名です。あまり気にせず読み飛ばしてください。 何を書くの？ 以下の通りです。 この記事で書くこと AWS のネットワークに関連するサービスの一部 詳解するサービスの基本的な内容 この記事で書かないこと AWS のサービスの詳解 AWS のサービスの応用 サンプルコード 構築のベストプラクティス 免責事項 この記事に書かれていることは弊社の意見を代表するものではありません。 この記事に書かれていることには一定の調査と検証を実施しておりますが、間違いが存在しうることはご承知おき下さい。 AWS の基本的なネットワークまとめ AWS の基本と言えばネットワーク、特に VPC ですが、商用で構築をするときには「S3 は VPC ゲートウェイを使うべき」といった話が平気で出てきます。

こんにちは、ホシイです 👋 以前の記事 で、ベクトル検索を気軽に試す例をご紹介しました。しかしこのベクトル検索、実際どのような用途に役立つのでしょうか。前回はアイディア次第… と濁して終わりましたが、今回はひとつその具体例を考えてみましょう。 Image captioning 前回の記事では、database (Redis) に保存されたテキストデータに対して embedding を生成し、それを用いて検索する例を実行してみました。テキストに対して検索するというのは想像がしやすいですが、対象がテキストであればなんなら正規表現などを用いても検索ができるものなので、そこまでありがたみを感じないかもしれません。 ということで、今回は画像を対象にしてみます。テキストで画像を検索するようなサービスをつくれたらいろいろと可能性が広がりそうです。 web を検索すると、AI を用いて画像キャプションを生成する例などもよく見られるようになりました。 例: Using GPT4 with Vision to tag and caption images OpenAI が何かと話題ではありますが、今回はわたしの都合で、利用しやすい Vertex AI の API を使用してみます。 やることは こちら の例のままです。Python の環境と、サンプルの画像ファイルがあれば準備が整います。(Google Cloud は billing 有効で認証ありの前提で… 🙏) こんな感じの AI の例としてよく使われている画像 を適当に用意して実行してみたところ、以下のような結果が得られました。 $ python app.py ['an astronaut is riding a horse on mars'] よさそうです！ システム全体の構成案 Google Cloud を使って、画像ファイルの保存と検索のシステムを検討してみました。(実証していません。仮想のものです) Image uploader service は、エンドユーザーが upload した画像ファイルを受け取り、Cloud Storage に保存します。また、database にそのファイルについてのエントリを保存します。この時点では embedding (vector) は空です。別の service に embedding 生成を指示するために、必要な情報を Pub/Sub に送信して処理を終わります。 Embedding generator service は、Pub/Sub からコマンドを受け取り、対象の画像ファイルを Cloud Storage から取得して image caption を生成し、さらにその embedding を生成します。これには Vertex AI の API を使えますし、他の AI service を用いることももちろんできます。生成した embedding は database の該当行に update します。 Search service は、ユーザーの入力したテキストを受け取り、embedding を生成、それを条件にして database に保存されたものに対しベクトル検索をかけます。得られた結果にもとづいて、Cloud Storage に保存された画像を取得してユーザーに表示します。 これで実現ができそうです。ここで使う database は、前回の記事でもご紹介した Redis を使ってもよいですし、Google Cloud でも Big Query などベクトル検索に対応した database がいろいろとありますので用途に合ったものを選んでみてください。

データベースの設計や運用において、エンジニアが最も頭を悩ませる問題の一つに、データの不整合を防ぐことがあるかと思います。これは信頼性やパフォーマンスの向上に直結するものとなります。 MySQL InnoDB Clusterは、複数のMySQLサーバー間でデータを同期し、一貫性のあるデータベースを提供するための強力な仕組みとなるものです。 そこでInnoDB Clusterの基本概念や、主要コンポーネントの役割についてまとめてみました。 MySQL InnoDB Clusterとは MySQLデータベースにおいて高可用性を実現するための技術で、自動フェイルオーバー機能を提供します。 これにより、データベースシステムのダウンタイムを最小限に抑えることが可能になります。 MySQL InnoDB Clusterを使用する目的と理由 InnoDB Clusterは、複数のデータベースサーバーを組み合わせて一つの「クラスタ」として機能させることで、以下のような利点を提供します。 クラスタとは、複数のサーバーが協力して一つの統一されたシステムとして動作することを指します。 これにより、高可用性、データの一貫性、スケーラビリティなどの目的を達成できます。 高可用性の確保 クラスタ内のサーバー間で自動フェイルオーバーとフェイルバック機能を提供し、システムのダウンタイムを最小限に抑えます。 データの一貫性と整合性 クラスタ内で動作している個々のデータベースサーバー（ノード）がデータをリアルタイムで同期することを可能にし、クラスタ内のすべてのノード間でトランザクションがリアルタイムで同期されます。 システムのスケーラビリティ クラスタ内のノードを柔軟に追加または削除することが可能です。これにより、アプリケーションの成長に合わせてデータベースのリソースをスケーリングすることができます。 その他可用構成との比較 MySQLレプリケーション マスターの障害発生時にスレーブが最新の状態でない場合、データのロスが発生するリスクがあります。 障害時にスレーブをマスターに昇格した後に、アプリケーションの接続切り替え作業が必須となります。 MHA for MySQL InnoDB Clusterと同じフェイルオーバーを自動化しますが、フェイルオーバープロセスには数秒から数分のダウンタイムが発生することがあります。 一度マスターから外れたノード（元のマスター）の復旧と再統合には手動での介入が必要となります。 MySQL Cluster(NDB Cluster) InnoDBで利用できません。 MySQL InnoDB Clusterの主要コンポーネントとその役割 以下に、InnoDB Clusterを形成する主要なコンポーネントを紹介し、それぞれがどのような役割を果たしているかを説明します。 MySQL Group Replication データの一貫性と整合性を保つためのレプリケーション機能を提供します。 MySQL Router アプリケーションからのリクエストを適切なデータベースサーバーにルーティングします。 MySQL Shell クラスタの設定、監視、管理の一元化を行うツールです。 構成図 簡単な構成図としてはこのようになります。 それぞれどのように連携し、冗長性を担保しているかをコンポーネント単位で説明します。

ベクトル検索 世間は AI 花盛り。パブリッククラウド各社の新機能発表でも AI 関連の機能が盛り沢山です。 AI アシスタントとのチャットや画像の生成といった機能がわかりやすい例ですが、他にも比較的地味ではありつつ強力な機能がいろいろあります。今日はそういった機能の中から、ベクトル検索を取り上げてみたいと思います。 たとえば Google Cloud では AlloyDB や BigQuery がベクトル検索に対応した database として名前があがっています。BigQuery では model の deploy や instance を用意する必要なく SQL から直接利用ができ 非常に便利そうです。 その機能としては、探したいことが書かれている文書を探したり類似する画像を探したりできる、いろいろと応用の夢が広がるものです。しかし、どうしても AI 関連の機能は「でも… お高いのでは?」という印象がつきまといます。実際、BigQuery とそこからリンクがはられている Vertex AI 関係の pricing のページ を見ましたが、実際にやってみる前にある程度正確に見積もるのはかんたんではないという印象を受けました。 そこで今回は、この夢のあるベクトル検索を、費用に心配無く体験してみたいと思います。 事前準備 : database として Redis を用意する 特に汎用キャッシュとして人気があり様々な場所で活用されている Redis ですが、ベクトル検索に対応した database のひとつです。クラウド上のマネージドサービスとしても利用可能な選択肢が多いですが、もちろんローカルで実行もできますので、今回はこれで試してみたいと思います。 ベクトル検索は、Redis の拡張版である Redis Stack で利用可能とのことなので、これをお手軽に Docker で起動してみます。こちら に Docker で起動するためのドキュメントがあります。 docker run -it --rm -d redis/redis-stack 何の追加設定も必要なく、デフォルト設定で問題なく起動しました。 念のため以下のように動作確認だけしておきました。(準備としては不要なステップです) 起動した container の shell に入って、サンプルデータ を load させてみます。

Dev Container ファンのホシイです。 わりと最近まで Intel CPU 搭載の MacBook を使ってきたのですが、経年には勝てず、更新のためにふだんの作業環境を Apple シリコン搭載の MacBook に切り替えました。 しかし、開発ターゲット (サーバー環境) は引き続き Intel が大多数ですし、チームでは Windows での開発も混在しているので、開発やテストは Intel (というか amd64 または x86_64) で行うのが望ましい状況です。特に、開発対象に native library への依存があったりするとなおさらですよね。 Container というか Docker の状況 Docker では、Apple シリコン Mac でも以下のようにして --platform を指定すれば x86_64 で動作させることができます。 ❯ docker run -it --rm --platform=linux/amd64 ubuntu root@a88443f3296c:/# arch x86_64 このとき、使用される container image ももちろん amd64 のものが pull されており、Docker CLI ではわかりにくいのですが、Docker Desktop であれば image の一覧で AMD64 マークが付いて表示され、判別しやすくなっています。(下の方で参考になる画像を貼っておきます) VS Code Dev Container 実行環境はよしとして、Visual Studio Code の Dev Container 機能にはもう少し複雑な状況があります。