技術情報 の記事一覧

本記事はGMOインターネットグループで複数ある開発者ブログのなかから人気の記事をピックアップして再掲載しています。機械学習や深層学習のビジネス応用を研究、社会実装をしているグループ研究開発本部 AI研究開発室のデータサイエンティストが寄稿した人気記事です。 ChatGPT に追加でデータを与える課題へのアプローチ Llamaindex で ChatGPT と連携した社内文書の QA ツールを構築した際にハマったことを書いていきます。 ChatGPT は非常に有用ですが、知っている情報が古いという問題があります。また社内の独自データは当然ですが学習されておらず回答に含めることができません。 この解決策として、外部から新しいデータを与えて回答を生成したいときは以下の方法があります。 Fine-tuningIn-Context Learning Fine-tuning はモデル自体にデータを与えて再学習させる方法です。回答精度も高く良い手法なのですが、2023年4月現在では推論精度の高い GPT3.5、GPT4 に対応しておらず davinci 等の GPT3 を使う必要があり、かつ API 利用料も通常の回答生成より高めのため、私は個人的に「もうちょっと待ってからやろうかな」と思っています。 In-Context Learning のほうはチャット文脈に情報を付与することでその会話の文脈の中で回答が可能になる手法です。Fine-tuning よりも弱い点としては一連のチャット文脈で送れる情報に限定されるとうところです。こちらは API の gpt-3.5-turbo を使ってお手軽に実装できるので、簡単なQAなどの要件であれば充分な成果が狙えると考えました。 今回やりたいこと 社内文書のデータを ChatGPT と連携した QA ツールを構築したいです。 In-Context Learningを用いた ChatGPT QA ツールのコアの部分はLangChainやLlamaindexを使って Python 数行で実装できます。 ただ作り始めて感じた疑問は、まともな回答が得られない場合、どのような点をチューニングできるのかということでした。 今回はここをQAシステムを開発しながら、改善できた点をいくつか紹介します。 結論ファースト ・Llamaindex はベクター検索を行ってから ChatGPT の API を実行するので、ベクター検索のデータの塊（チャンク）を整理して検索オプションパラメータを設定するとよい。 つくったもの まず今回の検証のベースとなるアプリケーションは、弊社 VPS サービス Conoha の API についてのドキュメントに基づいて回答する ChatGPT です。※Conoha API はインターネット上に公開されている情報なので、疑似的な課題設定です。実際のシステムは別のAPI仕様書を読み込ませています。 システム構成 ひとまず Python の Jupyter Notebook でコアな部分を構築しました。以下のライブラリに依存しています。 Llamaindex 0.5.11LLM の In-Context Learning をさらっと実装できるフレームワークです。公式ドキュメントhttps://gpt-index.readthedocs.io/en/latest/index.htmlGitHubhttps://github.com/jerryjliu/llama_index LangChain 0.0.135Llamaindex をはじめとしたツール群を OpenAI API を連携できるフレームワークです。他にも Google 検索と連携したりいろいろできるのでむしろこれが今後の潮流を生み出しそうな気がします。公式ドキュメントhttps://docs.langchain.com/docs/GitHubhttps://github.com/hwchase17/langchain Faiss faiss_cpu-1.7.3Facebookが開発したベクター検索ライブラリ。意味が近い文書を検索できます。ベクトル検索とか近傍探索という人もいます。距離計算をあらわす距離計算は L2 、コサイン類似度、ボロノイ領域 IndexIVFFlat を利用できます。検索対象データはローカルにファイルとして保存しています。GPU版とCPU版があり特にボロノイ領域の検索は高速なはず。 OpenAI API 0.27.4ChatGPT の API が簡単に実行できる公式ライブラリです。 将来的にはWebブラウザやSlackをインターフェースとして作り込むことを想定していますが、まだJupyter Notebookで動かしているだけなので、その範囲に限定して解説していきます。 ライブラリのインストールはさっとやってしまうとこんな感じです。 !pip install -U langchain !pip install -U openai !pip install -U llama-index !pip install -U faiss-cpu 各ライブラリの入門的な内容は他にもいい記事がたくさんあるので今回は割愛させてください。 ユースケース Conoha の Image 一覧を取る API に関する情報を gpt-3.5-turbo に問い合わせます。Conoha API の情報は10種類ほどローカルでベクター検索できるようになっています。Python でベクター検索して関連文書とともに gpt-3.5-turbo に API で質問をして回答を表示します。 はじめに書いたソースコード 元ネタとなる API の定義情報は以下のURLのものを出力してローカルでテキストファイルにしてあります。https://www.conoha.jp/docs/image-get_images_list.php Python です。 os.environ["OPENAI_API_KEY"] = "XXXXXXXXXXXXXXX" from llama_index import SimpleDirectoryReader, ServiceContext, GPTSimpleVectorIndex, LLMPredictor from langchain.chat_models import ChatOpenAI #data dirからテキストファイルの情報を取得 documents = SimpleDirectoryReader('data_conoha_api').load_data() # gpt-3.5-turbo を指定（現状デフォルトは davinci ） service_context = ServiceContext.from_defaults(llm_predictor = LLMPredictor(llm= ChatOpenAI( model_name="gpt-3.5-turbo")) # documents をもとに Embbeddings API を通信してベクター取得し GPTSimpleVectorIndex を生成 index = GPTSimpleVectorIndex.from_documents(documents, service_context=service_context) # save to disk index_json = 'index_conoha_api.json' index.save_to_disk(index_json) # プロンプト qry =" Conoha Imageの一覧を取るAPI のリクエストメソッド、URL、ヘッダー、リクエストボディ、をCURLの例とともに教えてください。RESの例も教えてください。 ?" # ベクター検索 + Chat Completion API 実行 response=index.query(qry) print(response) プロンプトはこちらです。" Conoha Imageの一覧を取るAPI のリクエストメソッド、URL、ヘッダー、リクエストボディ、をCURLの例とともに教えてください。RESの例も教えてください。 ?" 実行すると最終的に以下のような結果が得られました。 リクエストメソッドはGET、URLは/v2/images、ヘッダーにはX-Auth-Tokenが必要で、トークンIDが値として渡されます。リクエストボディはありません。CURLの例は以下の通りです。 REQ curl -i -X GET \ -H "Accept: application/json" \ -H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \ https://image-service.tyo1.conoha.io/v2/images RESの例は以下の通りです。 HTTP/1.1 200 OK Date: Tue, 09 Dec 2014 10:17:20 GMT Server: Apache Content-Length: 6102 Content-Type: application/json { "images": [ { "status": "active", "name": "testsnap", （以下、とても長いので省略します） はじめにしてはだいぶよい感じなので、同じ原理で社内の文書を適用すればあらゆるものが gpt-3.5-turbo に QA させたり要約させることができる見込みが立ちました。 Llamaindex 処理フロー Llamaindex の中の処理が何をやっているのかもう少し説明しておきます。処理順序はログで出してみるとどんなことをやっているかすぐにわかりました。 ベクターストアの構築処理 1 元ネタの文書のテキストファイルをローカルフォルダに入れておく。そのフォルダからdocumentオブジェクトを取得する。（Web上のURLでもよい）2 OpenAI の Embeddings API で元ネタ文書をベクター化し Index 作成。3 ローカルの専用ファイルとしてベクターを保存する。 質問回答の処理 1 「質問文」を受け取る。2 「質問文」を OpenAI の Embeddings API でベクター化。3 「質問文」のベクターでローカルファイルへベクター検索して、類似性が高い文章をいくつか取得。4 「質問文」と「類似性が高い文書」を一緒にプロンプトにまとめて OpenAI API で gpt-3.5-turbo に質問（Chat Completion API 実行）。5 「質問文」と「1回目の回答」と「類似性が高い文書その２」を一緒にプロンプトにまとめて OpenAI API で gpt-3.5-turbo に質問（Chat Completion API 実行）（Refine処理）。⇒ 類似性の高い文書があるだけ Refine 処理を繰り返す。6 最終回答を表示。 処理とリクエストを見ると、ローカルでベクター検索でひっかけてきた元ネタ文章の塊をそっくりプロンプトに入れてAPIのリクエストで渡しているだけというとても原始的な仕組みになっています。ChatGPT の画面と同様に Chat Completion API で1回のプロンプトに含められる情報には上限があります。これが Llamaindex の In-Context Learning の限界です。そのため情報の塊をどのように整理するかがちゃんとした回答を得られるかの重要なキーになってきます。 Llamaindex チューニング課題 ここからが本題です。 以下のような構成になっています。 本質的な課題 元ネタのテキストファイルをベクター検索のチャンクに収まるように意味の塊にする 個別の改善課題１ ベクター検索の2番目のドキュメントが正解だったりする問題２ 複数のドキュメントを読ませると間違える確率が上がる問題３ 失敗している理由がよくわからない問題４ ときおり英語で返してくる問題５ OpenAI API がタイムアウトする問題 将来役に立ちそうなTips ローカルファイルを小さくしたい 回答をもっと厳密にしたい 本質的な課題　元ネタのテキストファイルをベクター検索のチャンクに収まるように意味の塊にする いい回答を得るためには、プロンプトに何を含めるかが最重要課題です。元ネタのテキストファイルをベクター検索の１つの塊（チャンク）に収まるように意味の塊にすることで、正しいプロンプトを生成できるようになります。 Llamaindex における塊（チャンク）は元ネタのテキストファイルから GPTSimpleVectorIndex や GPTFaissIndex の document オブジェクト生成時に自動で生成されます。ログを読む限り１チャンクのサイズは以下のように見受けられました。・元ネタの 1 txt ファイル = 1 チャンクで作られていた・10kbを超えるファイルはチャンクが分割された Llamaindex ではベクター検索にヒットしたドキュメントが１つの塊（チャンク）で取得され gpt-3.5-turbo に丸ごと送られます。（下の「課題４ ときおり英語で返してくる問題」で内部のプロンプトの詳細を説明します。）丁度いいサイズにしておくことで Chat Completion API リクエストに余計な情報を入れなくて済むメリットがあると思っています。一方、極端に小型化すると一気に多くの情報を送れず ChatGPT が充分なレスポンスを作れないというデメリットがあり、トレードオフの関係にあります。 ほしい回答をしてもらうためには、この塊（チャンク）をいい感じにすることが本質的に重要になります。現段階でもっともシンプルに実現するためには、もともとのtxtファイルを「意味」の塊で分割してつくっておくことが必要です。（例えば1つのAPIについてのテキスト情報が10Kを超える場合、リクエストパラメータの解説で1つのテキストファイル、レスポンスパラメータで1つのテキストファイルとする）そして必要な情報がChatGPTに渡らない場合、テキストファイルを意味のまとまりで作り変えてチャンクを再生成するという工夫が求められると思います。 個別の改善課題を以下で紹介します。 課題１ ベクター検索の2番目のドキュメントが正解だったりする問題 ベクター検索では人間からの質問文とコサイン類似度が近いと判定された文章がレスポンスされてきます。よくある事象として、ベクター検索の結果の2番目のドキュメントが欲しい情報だったりすることがあります。（これはGoogle検索などでもよく見かけるケースだと思います） しかし Llamaindex はデフォルトではベクター検索結果の1番目のドキュメントだけを対象にして gpt-3.5-turbo に問い合わせ処理をするため、いきなりまともな回答が得られないという事態が発生します。 実例を見ていきましょう。 Conoha の VM イメージの一覧を取得する API についての質問をプロンプトに入れます。 qry =" Conoha Imageの一覧を取るAPI のリクエストメソッド、URL、ヘッダー、リクエストボディ、を Curl の例とともに教えてください。レスポンスの例も教えてください。 ?" qry =" Conoha Imageの一覧を取るAPI のリクエストメソッド、URL、ヘッダー、リクエストボディ、を Curl の例とともに教えてください。レスポンスの例も教えてください。 ?" 現状ベクターストアには「トークン発行」、「イメージ一覧取得」、「請求データ一覧取得」など10種類のAPIドキュメントが格納されています。この質問のベクター検索でひっかかったドキュメントはどういうわけか「トークン発行」でした。 DEBUG:llama_index.indices.utils:> Top 1 nodes: > [Node 2] [Similarity score: 0.812943] Conoha API トークン発行 - Identity API v2.0 当然 gpt-3.5-turbo に問い合わせるとこんなレスポンスが来ます。 DEBUG:llama_index.indices.response.builder:> Initial response:質問の内容が間違っています。提供された情報にはConoha Imageの一覧を取るAPIに関する情報は含まれていません。申し訳ありませんが、正しい情報を提供していただけますか？ 何かのワードが誤検知されてしまうとこういった検索結果の汚染が発生します。 similarity_top_k 解決方法として query 時のパラメータ similarity_top_k を指定します。 # ベクター検索 + Chat Completion API 実行response=index.query(qry, similarity_top_k=3) similarity_top_k は類似文書をベクター検索した際に上位何件まで返しますかという設定です。複数のドキュメントをヒットさせることができると Llamaindex は繰り返し処理をするため正解の文書を読む確率が上がるわけです。 しかしこれによってまた次の問題が発生します。 課題２　複数のドキュメントを読ませると間違える確率が上がる問題 複数の文書をもとにして回答生成をするとノイズになってしまい、結果として変な回答が出ることがあります。 再び実例を見ていきましょう。 上記のイメージ一覧取得APIの質問からベクター検索でひっかかったドキュメントは以下の3つでした。 1つ目が「トークン発行」2つ目が「イメージ一覧取得」3つ目が「請求データ一覧取得」 DEBUG:llama_index.indices.utils:> Top 3 nodes: > [Node 2] [Similarity score: 0.812943] Conoha API トークン発行 - Identity API v2.0 > [Node 4] [Similarity score: 0.807114] イメージ一覧取得(Glance) - Image API v2 > [Node 3] [Similarity score: 0.78922] 請求データ一覧取得 - Account(Billing) API v1 2つ目が正解なのですが、3つ取得してしまうことで処理的に非常に効率が悪い状況が発生します。 1 まず質問と1つ目の情報をくっつけたのプロンプトを飛ばします。2 質問と1つ目のレスポンスと2つ目の情報をくっつけて次のプロンプトを飛ばします。3 質問と2つ目のレスポンスと3つ目の情報をくっつけて次のプロンプトを飛ばします。 これが Llamaindex の Refine と呼ばれる回答精査処理なのですが、仮に 2 で正解していても 3 が入ることでノイズになってしまい gpt-3.5-turbo が変なことを言い出すことがあります。（それに3回のやりとりは API の token を結構消費してしまうので、コスト的にもあまりよくありません。） required_keywords この解決のためには検索結果からノイズの除去が必要です。パラメータで検索時の必須キーワードと除外キーワードの設定を行うことでノイズ除去ができます。 例えば上記の問題の場合「イメージ」という単語を絶対に含んでいますということ指定します。 key_str="イメージ" exc_str="" # ベクター検索 + Chat Completion API 実行 response=index.query(qry, similarity_top_k=3, required_keywords=[key_str], exclude_keywords=[exc_str] ) こうすることで正確な情報を伝達できるようになり、回答が改善できます。（jupyterなのでべた書きで実行してしまっていますが、画面からプロンプトで受け取るときはフォーマットを決めてプログラム上で加工などをする必要があります。） similarity_top_k で3つの文書を取得することはメリットもデメリットもあるので、required_keywords を活用する工夫で改善することができます。 課題３ 失敗している理由がよくわからない問題 以上のような問題はただ実行しているだけだと全く分析できません。ちゃんと元ネタのドキュメントに答えが書いてあるのに、なんで読み込めないんだ！とイライラが募るのでログを出してやりましょう。 import logging # ログレベルの設定 logging.basicConfig(stream=sys.stdout, level=logging.DEBUG, force=True) 当たり前なんですがログを出すと結構な情報がわかります。 OpenAI API の実行回数OpenAI API の処理時間OpenAI API に送った Token 数ベクター検索に引っかかったドキュメントのコサイン類似度 response.get_formatted_sources() もうひとつ。gpt-3.5-turbo が回答を生成したときに一緒に送ったドキュメントを出力する機能があります。 response.get_formatted_sources() たとえば上記の例で3つのドキュメントが参照されたのはこちらのように出力されました。 > Source (Doc id: 25f2390e-7068-4331-b5b2-312754ed49a8): Conoha API トークン発行 - Identity API v2.0 Description 有効なトークン情報を取得する Request URL identity API v2.0... > Source (Doc id: db57709a-25b4-4272-8bf1-23993ab04d63): イメージ一覧取得(Glance) - Image API v2 Description イメージ一覧を取得 Request URL Image 一覧API v2 GET /v2/im... > Source (Doc id: 95011a8f-a0ae-46b8-b181-5dcb8c26423f): 請求データ一覧取得 - Account(Billing) API v1 Description 課金アイテムへの請求データ一覧を取得します。 Request URL billing API ... これでソースとなっているインデックスの文章を確認できます。required_keywordsが適用された後の結果が出るので、その効果検証も可能です。もし変なものが参照されてしまっているのであれば、元ネタの文章を書き直したり必須キーワードを修正したりすることで検索制度を改善できる可能性があります。 課題４ ときおり英語で返してくる問題 処理の中では初回の質問チャットと、回答に別情報を付与して精査するRefineのチャットの2回が行われます。そこでなぜか突然 API から英語でレスポンスがかえってくることがあります。この原因は初回QAのプロンプト、 次の精査プロンプトがデフォルトで英語で書かれているためです。 対処法として、質問文に「日本語で返してください」と追記するのが手っ取り早い方法です。それでもデフォルトの英語が残っていると gpt-3.5-turbo はこの文脈では英語をつかっていいんだなと解釈してしまうことがあるので、サービス的に完全に除去したい場合はデフォルトのプロンプト自体を日本語に修正することが確実な方法です。 from llama_index.prompts.prompts import RefinePrompt, QuestionAnswerPrompt QA_PROMPT_TMPL = ( "私たちは以下の情報をコンテキスト情報として与えます。 \n" "---------------------\n" "{context_str}" "\n---------------------\n" "あなたはAIとして、この情報をもとに質問を日本語で答えます。前回と同じ回答の場合は同じ回答を行います。: {query_str}\n" ) qa_prompt = QuestionAnswerPrompt(QA_PROMPT_TMPL) REFINE_PROMPT = ("元の質問は次のとおりです: {query_str} \n" "既存の回答を提供しました: {existing_answer} \n" "既存の答えを洗練する機会があります \n" "(必要な場合のみ)以下にコンテキストを追加します。 \n" "------------\n" "{context_msg}\n" "------------\n" "新しいコンテキストを考慮して、元の答えをより良く洗練して質問に答えてください。\n" "コンテキストが役に立たない場合は、元の回答と同じものを返します。") refine_prompt = RefinePrompt(REFINE_PROMPT) # ベクター検索 + Chat Completion API 実行 response=index.query(qry, text_qa_template=qa_prompt, refine_template=refine_prompt, similarity_top_k=3, required_keywords=[key_str] ) 日本語のほうがtokenが多くなるので API 利用コストが上がってしまうという点だけご留意ください。 公式にも記載がありました。https://gpt-index.readthedocs.io/en/latest/how_to/customization/custom_prompts.html 課題５ OpenAI API がタイムアウトする問題 APIから長いレスポンスが来る場合非常に重くなりますが、デフォルト60秒でタイムアウトします。ぜんぜんレスが返ってこない場合は request_timeout=120 などとしてやりましょう。 from langchain.chat_models import ChatOpenAI from langchain.callbacks.streaming_stdout import StreamingStdOutCallbackHandler from llama_index import LLMPredictor,ServiceContext llm=ChatOpenAI( request_timeout=120, #streaming =True, #callback_manager=CallbackManager([StreamingStdOutCallbackHandler()]), model_name="gpt-3.5-turbo") llm_predictor = LLMPredictor(llm=llm) service_context = ServiceContext.from_defaults(llm_predictor = llm_predictor) streaming が動けばよかったのですがうまくいきませんでした。どうやらライブラリの実装が移行期のようで、マニュアル通りやってもソースコードと整合性があっていないように感じました。 ここまでで今回のアプリケーションで具体的に役に立った部分を説明しました。 ここからは将来的に役に立ちそうなチューニング箇所を書いていきます。 Tips１　ローカルファイルを小さくしたい ローカルのファイルを読んでいるだけなのではじめに利用した SimpleVectorStore でも充分に早いですが、Llamaindex では Faissという Facebook が開発したベクター検索ライブラリが使えます。こちらは GPU も対応しており、とにかく早いことがウリです。（今回サイズが大きなものが用意できず検索速度の比較数値を出せないのが悔やまれる）また Faiss を使うとファイル容量が SimpleVectorStore の3分の1になったので、将来的に大規模化することを想定するとメリットになるだろうと考えています。 検索用 index オブジェクトの生成を丸ごと置き換えてやります。GPT SimpleVectorStore 同様に GPTFaissIndex でもコサイン類似度を利用したコードで書いています。 # Faiss 連携 import faiss from llama_index import GPTFaissIndex # dimensions of text-ada-embedding-002 d = 1536 # コサイン類似度 faiss_index = faiss.IndexFlatIP(d) # APIを実行しFaissのベクター検索ができるようにする index = GPTFaissIndex.from_documents(documents, faiss_index=faiss_index, service_context=service_context ) # save index to disk index.save_to_disk( 'index_faiss.json', faiss_index_save_path="index_faiss_core.index" ) 他にもベクター検索のエンジンは複数対応しているようでした。 Postgreshttps://gpt-index.readthedocs.io/en/latest/guides/tutorials/sql_guide.htmlPineconehttps://github.com/jerryjliu/llama_index/tree/66db86d2e875fb47384a77a0469bc6c6f45c866e/examples/data_connectors Tips２　回答をもっと厳密にしたい temparetureパラメータで回答の多様性を指定できます。デフォルトは0.7のようですが変なことを言いすぎるときはここを減らしてください。Web 上のサンプルコードではみなさん tempareture = 0 をしていて、正確性を最重視する設定になっています。 # ベクター検索 + Chat Completion API 実行 response=index.query(qry, tempareture = 0, text_qa_template=qa_prompt, refine_template=refine_prompt, similarity_top_k=3, required_keywords=[key_str] ) 未解決：元ネタのドキュメントがどのように Embeddings API に送られているか ここは最後までよくわからなかったところです。 ベクター検索につかうデータを生成するとき、 text-embeddings-ada-002 モデルを利用すると最大token数は8192が制限になります。ただ、DEBUGログでは14000tokensも送っていたのでパッと見でオーバーしています。元ネタのテキストを小分けのファイルにしたりしてみたのですがが、分割した後でもDEBUGログ上でAPIの実行回数が1回でした。これは上限にひっかからないの？実は失敗しているの？と思いながら結局よくわかりませんでした。 感想 In-Context Learning が非常に簡単に使えて楽しかったです。ただ簡単ゆえに、どちらかといえばベクター検索精度の問題になってしまったため、使い道は QA のような短答問題に絞られるかなあと思っています。やっぱり Fine-tuning をがっつりやるのが本番になるのではないでしょうか。ただ llama_index-0.5.11 とか langchain-0.0.135 とか、こんな出来立ての OSS をまじめに検証するもんじゃないですね。あまりにホットすぎて2週間ぐらいでバージョンがどんどん変わります。その都度引数が変わってやり直しの憂き目にあいました。もう少し安定しないと実践投入は悩むところ。 最後に宣伝です！ グループ研究開発本部の次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットの新規サービスの開発を行うエンジニアを募集しています。募集職種一覧 からご応募をお待ちしています。

Perlを中心としたIT関連カンファレンス「YAPC::KYOTO- 2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『4PB（ペタバイト）を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ』をお届けします。 登壇者 三上 烈史（みかみ つよし）　@rsym1290GMOペパボ株式会社 技術部プラットフォームグループ https://speakerdeck.com/rsym1290/4petabaitowochao-eruobuziekutosutoreziwo-hadoueakaraapurikesiyonnikakete-yun-yong-surunouhau 30days Albumを支えるオブジェクトストレージ 三上が今回のテーマとして取り上げるのは、写真共有サービス「30days Album」とプライベートなオブジェクトストレージ「Bayt」です。 GMOペパボでは、独自にオブジェクトストレージを保有しており、複数のサービスで活用しています。一般的なサービスでオブジェクトストレージを利用することも多くなっていますが、自らオブジェクトストレージを作って運用することになるという例はなかなかないのでは、と三上は話します。そうしたことから、どのようにオブジェクトストレージを構築して運用してきたのか、そのノウハウも含めて紹介されました。 GMOペパボのサービス内で、特にオブジェクトストレージが重要な役割を果たしているのが、30days AlbumとBaytという2つのサービスです。この2つのサービスには密接な関係があります。 GMOペパボの提供するサービス一覧。この中でも特にオブジェクトストレージを活用しているのが30days AlbumとBaytです。 低コストの自前オブジェクトストレージ 30days Albumは、撮影した写真や動画をアップロードして共有できるアルバム形式のサービスで、パスワードではなく「合い言葉」という形で認証して共有できます。2008年にスタートしたサービスで、2023年3月16日の時点でおよそ8.7億枚の写真を保管しているそうです。 30days Albumは写真や動画の共有サービス。約8.7億枚の写真を保管しています。 Baytは、GMOペパボ独自のプライベートなオブジェクトストレージです。GMOペパボの各サービスがアップロード先として利用していて、S3互換であることが特徴の1つです。AmazonS3で利用できるGetObjectやPutObjectといった一部のAPIを実装していて、S3と同じような感覚で利用することができるようになっています。 BaytはS3互換のプライベートなオブジェクトストレージ GMOペパボでは、ECサイト作成支援「カラーミーショップ」で商品画像のアップロード先や、ホームページ作成サービス「グーペ」のコンテンツのアップロード先などで利用されています。 S3やGCS（Google Cloud Storage）といった既存のオブジェクトストレージを使わずに、なぜわざわざ自前で開発しているかというと、その理由として30days Albumの運用を通じて培った知見とコストが関係していると三上は説明します。 前述の通り30days Albumのスタートは2008年。サービスの特性上、オブジェクトストレージが必要になるので、まずはPerl製のMogileFSを使ってオブジェクトストレージを構築しました。その後、2015年頃になると、カラーミーショップなどほかのサービスを含めて事業規模が拡大し、各サービスでもオブジェクトストレージのニーズなどが高まってきたそうです。 当初はOpenStack SwiftやS3を使うといった案があったものの、最終的にはS3互換のAPIを実装することでオブジェクトストレージ提供することにしたそうです。理由としては、この時点で30days Albumで7年間かけて自前のオブジェクトストレージで運用した実績があり、コストがかからない、実装の手間が削減できる、運用も安定する、という点があったそうです。 こうして生まれたのがBaytで、それまでサービスごとにストレージが異なっていたのを、統一されたオブジェクトストレージに統合できるようになりました。 とはいえオブジェクトストレージをBaytだけに限定したわけではなく、コストを重視するならBayt、機能を重視するならS3／GCSという使い分けになっています。最低限のオブジェクトストレージの機能でアップロードするだけでいい場合などはBayt、それで機能が足りなければS3などを使うという形になっているとのこと。 MogileFSとBaytの構成 BaytのベースとなったMogileFSは、スケーラブルな分散ストレージを構築できるOSSで、4つの要素で構成されています。 client：リクエストを発行するtracker：クライアントからのリクエストを受け付けるdatabase：オブジェクトの保存場所やストレージを構成するサーバー・デバイスの情報を格納したデータベースstorage node：実際にオブジェクトが格納される場所で、GMOペパボではC言語で実装されたcmogstoredを利用 MogileFSのアーキテクチャ。4つの要素から構成されています。 続いて30days Albumに当てはめた構成について説明されました。前段階としてユーザーが利用するフロントエンドとしてのアプリケーションがあり、アップロードされた画像のサムネイルを作成するなどの画像処理のためのサーバーがあります。続いて30days Album用のAPIがあり、これが「client」に相当します。 さらにtrackerやdatabase、storage nodeが存在しており、storage nodeではたくさんのHDDを並べてストレージサーバーが構築されています。 30days Albumの構成図 Baytの場合、MogileFS運用の知見をそのまま生かすため、こうした構成をそのまま利用しました。ここに、Baytとして必要なアプリケーションやフロントのリバースプロキシなどを追加して実装しています。 さらにバックエンドをそのままにBaytを追加しています つまり、フロントは分かれているけれどもバックエンドは共有されているということで、物理的には30days AlbumとBaytのそれぞれのオブジェクトが混在している形になっています。1つのHDDの中に30days Albumでアップロードされた画像も、Baytにアップロードされたコンテンツが保管されているわけです。 ここでMogileFSのドメインという仕組みを利用して、あるオブジェクトが30days Album、カラーミーショップなどのいずれに属しているかを論理的に区別しています。また、複数のストレージサーバーを構成していることで、HDDが1つだけでなくストレージサーバー自体が1つ壊れても復旧できるよう冗長性も確保しています。 30days AlbumとBaytのオブジェクトはバックエンドで共有化されていて混在していますが、ドメインの仕組みによって論理的に区別されています ハードウェアはやみくもに増やせない、その3つの課題 続いて三上はハードウェアに関して取り上げます。S3やGCSのようなクラウド全盛時代になると、ハードウェアを意識することは少なくなってきます。しかし、クラウドを支えているのはハードウェアなので、運用側は意識する場面があると三上は話します。 GMOペパボの場合、ストレージサーバーとして15台を運用しており、その中にHDDが386本存在（3月16日時点）。総容量は4.58ペタバイトという容量になっています。しかもこうした容量は常に増え続けるため、十分な容量を常にキープし続ける必要があります。そのため、大容量HDDを確保して増設していくことになります。 ストレージサーバーの台数は15台、HDDは386本となり、総容量は4.58ペタバイトに達しています しかし、やみくもにただ増設すればいいというわけではないと三上は指摘します。そこにある課題は3つです。 サーバーラックは無尽蔵に増やせない基本的にはサーバラックは月額払いでの契約が一般的で、「データセンターにもよりますが、1ラックで月額20～30万円」と三上は言います。ラックの追加もむやみにできるわけではなく、サーバラックを増やせば増やすほど運用コストも上がります。サーバーもHDDも寿命があるハードウェアはいずれ壊れるものです。HDDが壊れればストレージ総容量が減るし、それを見据えた増設が必要です。壊れたあとの対処は大変なので、できれば壊れる前に廃棄するのが理想です。サーバーの性能は相対的に劣化するハードウェアに関する技術は日々進歩しており、年々より高性能なサーバーが登場します。こうしたサーバの登場により、導入した当時のサーバは時間の経過に伴い相対的に性能面で劣ることになります。また、サービスを長年運用するとサービスが成長し、導入当時の性能だけではいずれ耐えきれなくなることが考えられます。そのため、単にサーバーを導入すればいいというわけではないと三上は言います。 こうした課題に対して三上は、「ライフサイクルを意識したハードウェアの運用が必要」と指摘します。 ライフサイクルを意識して4ペタバイトまでストレージを運用 GMOペパボでは、ストレージサーバーの帯域や容量のライフサイクルを作って運用しています。 例えばサーバーラックに3台のストレージサーバーがあり、HDDが288TBの容量だった場合に、6TB×16ベイのサーバーを1つ廃棄すると、容量は192TBに減少します。しかし、ラックのスペース自体は確保できるので、容量の大きいより良いストレージサーバーを導入することができます。例えば18TB×16ベイのストレージサーバーを増設すると、トータル容量も480TBに拡大できます。 ストレージサーバーの増設・退役のライフサイクルを意識することが重要です サーバーの選定も重要です。オブジェクトストレージは容量が命なので、1U、2Uといったサーバーのサイズの中でどれだけHDDを搭載できるかが重要になります。GMOペパボでは、2Uサイズで16ベイのHDD、または4Uで36ベイのHDDを搭載したサーバーを中心に利用していると三上は説明。 30days AlbumとBaytの運用経験から、cmogstoredはCPUやメモリの性能はそれほど求められていないということが分かり、サーバーを選択しやすいというメリットもあるそうです。30days AllbumとBaytでは、CPUはインテル Xeon Bronze系、メモリは8GB程度であれば運用可能とのことです。 HDDはデータセンター向けの製品を採用。常時稼働が前提なので耐久性の高いものを選択しています。保証期間も3～5年の保証期間で利用できるため、データセンター向けHDDが基本になります。 ちなみに、1ドライブ当たりのデータ容量が大きく、容量単価が安いという点からSSDではなくHDDを採用しているそうですが、Baytの要求水準からすると、IO性能はHDDでも十分とのことでした。 三上は余談といいつつ、ここ最近の半導体不足の影響を受けてストレージサーバーの納期が延びている点を指摘します。今までは2カ月程度だった納期が、在庫がない場合は半年から1年先になってしまっているそうで、納期から逆算した発注計画が必要だと言います。 為替もインパクトがあり、海外製サーバーを採用した場合に円安の影響を受けやすい点も課題です。前年の段階で予算計画を立てても、為替の変動で想定していたサーバー構成だと予算オーバーしてしまう場合もあるため、こうしたリスクもあるとのことです。 こうして運用していくストレージサーバーですが、ハードウェアの寿命があるため最終的には退役、廃棄までが運用になります。壊れてからでは遅いので、壊れる前に退役・廃棄をして、それによって新しいストレージサーバーを入れられるようになります。 とはいえ、HDDが急に壊れてしまうことはあるので、その対策も必要になります。GMOペパボではsmartmontoolsを利用したHDDの監視を行っています。これによって不良・故障を検知しており、問題を検知すると自動でメールが送信されます。これを使って自動でissueを立てるという仕組みになっているそうです。 壊れたHDDの切り離しはMogileFSの機能を利用。MogileFSではHDDを5つのステータスで管理しており、切り離す場合にはdeadフラグを設定して使用できなくします。保存されているデータは冗長構成で他のドライブにも保存されており、MogileFSは切り離しでHDDが減っても、冗長性を維持するよう自動でレプリケーションをやり直してくれるという機能もある点も特徴です。 こうして運用した結果、4PBを超える容量に達したオブジェクトストレージ。実際の利用状況を見ながら、使用量を上回るHDD容量を維持し続け、その中で退役や廃棄を行ってきていたそうです。 リアルタイムで計測してきたというストレージ容量。実際の使用量である赤線が総容量の青線に達しないように運用を続けており、退役で一時的に容量が減っても右肩上がりに容量が上がっています。 BaytにおけるS3 REST APIの実装例 前述の通り、BaytはS3のREST APIを一部導入したオブジェクトストレージです。S3のAPI Referenceに従って実装したREST APIを備えていますが、すべてのAPIやオプションではなく、頻繁に利用されるAPIに限定していて、オプションも必要最低限に絞っています。基本的にはS3と同じようにBaytを利用できるという形になっています。 Baytに実装されているREST API 実際の実装では、MogileFSをバックエンドとして、BaytはRuby on Railsで実装、フロントにREST APIが提供されているという構成です。GetObjectを例にすると、まずはBaytのAPIにリクエストが送信されたのちに、APIがデータベースを参照してオブジェクトのコンテンツタイプやファイルサイズなどのメタデータを取得します。 このデータベースはMogileFSとは別に用意してあり、同時にMogileFSに対してオブジェクトの格納先の問い合わせが行われます。その格納先が抽出されると、そのパスが返ってきたらリバースプロキシが実際のオブジェクトを取得してレスポンスとして返す、という流れになります。 BayではMogileFSをバックエンドとしたREST APIを実装しています Baytの構成図に当てはめるとこのような構成になっています BaytはS3へ、30days Albumもハイブリッドに 実はBaytは、今後S3へ移設することを予定しています。コストを重視したBaytを採用してきましたが、2015年以来サービスが成長を続けており、予算をさらにかけてより機能面を重視しようという方向になってきたといいます。すでにグーペではS3への移管が完了しているとのこと。しかし、30days Albumに関しては同様の運用を継続する方針です。 とはいえ、まだ課題があると三上は話します。1つ目が運用の属人化で、これまで説明してきたハードウェアのライフサイクルの運用やMogileFSに関しても、詳しい人間が限られていて、その人間に運用が集中しているそうです。 対策としては、SREとして運用のtoil削減や自動化による運用負担の軽減を模索。ドキュメントを充実させるほか、オンコールトレーニングによる障害対応力の向上を図ります。こうした話は、同じYAPCにおけるGMOペパボ技術者の講演（https://developers.gmo.jp/31489/）でも話していた内容です。 また、2008年からという長いサービスであるがゆえに、30days Albumのサービス全体がレガシー化しているというのも課題で す。30days Albumは、ストレージ以外の部分もオンプレミス中心の設計になっており、ストレージ以外のハードウェアも管理しなければならないため、これをクラウドとのハイブリッドにすることでハードウェアの運用負荷の軽減を図りたい考えです。 最後にYAPC::Kyoto 2023の写真を30days Albumへぜひ投稿してくださいという挨拶で締めくくられました。アルバムは実際に https://30d.jp/yapcjapan/5 で公開されているのでぜひご覧ください。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=vO5CbCpJ9_g

こんにちは。グループ研究開発本部 次世代システム研究室です。議事録作成に手間がかかるため、コア業務に集中できないと感じている方は多いでしょう。このような方におすすめなのがAIを活用した議事録の自動作成です。今回のブログでは、OpenAI社が開発したChatGPT APIとWhisperを使った音声ファイルの要約システムの構築を紹介したいと思います。 1.やりたいこと 目的：音声ファイルの要約を自動化すること 使用する技術：OpenAIのChatGPTとWhisper 実現手段： Dockerで音声自動要約専用サーバーを構築Flaskを利用して音声ファイルを処理するAPIを作成Whisperで音声ファイルをテキストに変換ChatGPT APIで要約を生成要約テキストをユーザーに返却 2.環境構築 2-1.Whisperサーバー構築 Whisperとは、OpenAIが開発している汎用的な音声認識モデルです。インターネット上から収集した68万時間におよぶ音声データで学習され、音声翻訳や言語識別だけでなく、多言語音声認識を行うことができるマルチタスクモデルでもあるモデルになります。Whisperの日本語の単語誤り率は6.4%であり、他の言語と比較しても高い精度で文字起こしが可能だと言えます。 今回はDocker環境を使うので以下のDockerfileを実装しました。 ROM python:3.10-slimWORKDIR /python-dockerCOPY requirements.txt requirements.txtRUN apt-get update && apt-get install git -yRUN pip3 install --upgrade pipRUN pip3 install -r requirements.txtRUN pip3 install "git+https://github.com/openai/whisper.git"RUN pip3 install --upgrade openaiRUN apt-get install -y ffmpegCOPY . .EXPOSE 5000CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"] 音声自動要約専用サーバーは、Python 3.10-slimベースのDockerイメージを使用し、requirements.txtで指定されたPythonパッケージをインストールします。WhisperとOpenAIのPythonパッケージをインストールし、FlaskフレームワークでAPIを実装します。APIをポート5000で実行するように指定しています。また、音声・動画の変換、再生、録画などを行うためffmpegもインストールしておきます。requirements.txtに以下の内容で準備します。 autopep8==1.6.0certifi==2021.10.8charset-normalizer==2.0.7click==8.0.3et-xmlfile==1.1.0Flask==2.0.2idna==3.3itsdangerous==2.0.1Jinja2==3.0.2MarkupSafe==2.0.1numpy==1.21.3openai==0.19.0openpyxl==3.0.9pandas==1.3.4pandas-stubs==1.2.0.35pycodestyle==2.8.0python-dateutil==2.8.2python-dotenv==1.0.0pytz==2021.3requests==2.26.0six==1.16.0toml==0.10.2tqdm==4.62.3urllib3==1.26.7Werkzeug==2.0.2 2-2.ChatGPT API向けの設定 2023年3月2日（米国時間では1日）、OpenAIのChatGPTのAPIが公開されました。プログラムからChatGPTを使うため、APIキーを発行してもらわなければなりませんので、OpenAIにログインし、右上のアイコンからView API Keyをクリックします。APIのページにいけるので、そこから新しいシークレットキーをcreateします。作成されたsecret keyはメモしておきましょう。OpenAIから取得したAPIキーを.envファイルを設定しますしょう。 LASK_APP=appFLASK_ENV=development# Once you add your API key below, make sure to not share it with anyone! The API key should remain private.OPENAI_API_KEY=sk-jxxxxxxxxx 2-3.音声自動要約アプリの実装 さて、APIサーバーのエントリースクリプト(app.py)を実装しましょう。このソースコードは、Flaskフレームワークを使用してWebアプリケーションを構築し、Whisper及びChatGPT APIを使用して音声ファイルを自動要約します。「/summary」エンドポイントにPOSTリクエストを送信すると、音声ファイルを受け取り、Whisperを使用してテキストに変換し、OpenAI APIを使用して自動要約を作成し、JSON形式で結果を返します。中身は以下の通りです。 from flask import Flask, abort, requestfrom tempfile import NamedTemporaryFileimport osimport whisperimport openaiimport torch# NVIDIA GPUが利用可能かどうかを確認torch.cuda.is_available()DEVICE = "cuda" if torch.cuda.is_available() else "cpu"# Whisperモデルをロードするmodel = whisper.load_model("medium", device=DEVICE)# OpenAPI APIキーを設定するopenai.api_key = os.getenv("OPENAI_API_KEY")app = Flask(__name__)@app.route("/")def welcome():return "Welcome to my Blog Post about ChatGPT and Whisper!"@app.route('/summary', methods=['POST'])def handler():if not request.files:# ユーザーがファイルを渡さなかった場合は、400 (Bad Request) エラーを返すabort(400)results = []# ユーザーが渡したすべてのファイルに対してループするfor filename, handle in request.files.items():# 一時ファイルを作成する.temp = NamedTemporaryFile()# ユーザーがアップロードしたファイルを一時ファイルに書きこむhandle.save(temp)# Whisperモデルで音声の一時ファイルからテキストを取得するresult = model.transcribe(temp.name)# Sテキストを要約するsummary_result = summary_text(result['text'])# 結果オブジェクトを作成するresults.append({'transcript': result['text'],'language': result['language'],'summary': summary_result,})# JSON形式で結果を返却するreturn {'results': results}def summary_text(transcribed_text):if len(transcribed_text) == 0:return ""print(generate_prompt(transcribed_text))try:response = openai.Completion.create(model="text-davinci-003",max_tokens=1024,stop=None,prompt=generate_prompt(transcribed_text),temperature=0.7,)print(response)return response.choices[0].textexcept Exception as e:print(e)return ""def generate_prompt(transcribed_text):return """以下の文章は日本語におかしいなところを修正してください。修正した文章を説明不要で箇条書き文章のみに簡潔に答えてください:{}""".format(transcribed_text) summary_text関数は、テキストを受け取り、OpenAI APIを使用して自動要約を作成します。 関数のパラメータは以下のとおりです。 model：使用する言語モデルの種類を指定する（ここでは"text-davinci-003"を使用） max_tokens：生成される文章の最大トークン数を指定する（ここでは1024を指定） stop：生成される文章の停止語を指定する（ここでは指定せずNoneとしている） prompt：生成される文章のプロンプトとなる文章を指定する（ここではtranscribed_textを引数として渡してgenerate_prompt()で作成） temperature：文章生成のランダム性を調整するパラメータ。0に近いほど一意な文章が生成されやすく、1に近いほど一般的な文章が生成されやすくなる。0から1の値を指定する（ここでは0.7を指定）。 このChatGPTのAPI仕様が公開されているので興味の方はご参照ください。 2-4.アプリケーションサーバを起動 早速、dockerコマンドで音声自動要約サーバーのImageをビルドしましょう。Dockerfileが存在するディレクトリに移動し、以下のコマンドを実施しましょう。 docker build -t audio-summary-api . 大量の依存関係を解決するために必要なパッケージをインストールしたり、GPUカード対応のためサイズの大きいファイルのダウンロードが発生するのでビルド時間が10分以上になります。 Docker Imageをビルドできたら次のコマンドでAPIサーバを立ち上がりましょう。 docker run -p 5000:5000 audio-summary-api ここまでは音声自動要約サーバーの準備ができました。 3.実験結果と評価 3-1.自動要約された音声ファイル 早速、音声自動要約APIを検証しましょう。次のcurlコマンドを使用してこのAPIを検証できます。 curl -F "file=@/path/to/file" http://localhost:5000/summary 結果として、JSONオブジェクトに以下の項目が含まれるはずです。 language: Whisperが音声ファイルから認識したテキストの言語 transcript: Whisperが音声ファイルから認識したテキストの本文 summary: ChatGPTが要約したテキスト 今回は、次世代システム研究室の新卒メンバー1年目後のインタビュー動画から音声を抽出して構築したシステムでテキストに要約したいと思います。yt-dlpなどPythonのライブラリを使用して音声抽出が可能ですが、今回のブログでは対象外としました。 3-2.要約結果 ChatGPT APIの出力を安定するまでモデルを切り替えたり、Promptの内容をチューニングしたりする必要がありますしたのでソースコードに記載したPromptのように対応しましたが、ChatGPTのInputとなるWhisperのOutputをチューニングが大事ですね。ちなみに、Whisperモデルは以下の９種類がありますが、今回は日本語を対応する多言語モデルのみ使います。 SizeParametersEnglish-only modelMultilingual modelRequired VRAMRelative speedtiny39 Mtiny.entiny~1 GB~32xbase74 Mbase.enbase~1 GB~16xsmall244 Msmall.ensmall~2 GB~6xmedium769 Mmedium.enmedium~5 GB~2xlarge1550 MN/Alarge~10 GB1x 各Whisperモデルを検証するため、app.pyにてwhisper.load_modelにモデル名を指定しましょう。 # Load the Whisper model:model = whisper.load_model("base", device=DEVICE) 音声ファイルを指定して、自動要約APIを実行しましょう。APIの実行には、私自身がよくPostmanを使っているので、今回もPostmanで検証を行いたいと思います。使えませんね。。ベースモデルだとWhisperのOutputとなるtranscriptが非常に精度が低いため、音声からテキストに変換した結果は全く使えませんでした。。Whisperベースモデルの検証結果に加えて、上位のモデルも含めた検証結果を確認したいと思います。そのため、ソースコードにてWhisperモデルをmediumに設定して検証してみましょう。 # Whisperモデルをロードする model = whisper.load_model("medium", device=DEVICE) 見事、mediumモデルを使うとtranscriptの内容がかなり改善されたため、ChatGPTによる要約結果であるsummaryも大幅に改善されました。厳密に言えば、この要約文章はまだ改善の余地があると思いますが、意味はかなり明確になりました。今回の検証結果は以下のテーブルでまとめました。 Whisper modelモデルサイズ音声ファイルサイズ初回サーバ起動時間自動要約時間精度tiny72.1MB950Kb40秒15秒非常に低いbase139MB950Kb1分38秒17~20秒非常に低いsmall461MB950Kb4分19秒28秒低いmedium1.42GB950Kb14分08秒1分24秒良いlarge2.87GB950Kb起動不可（リソース不足）-使えない 検証結果からみるとWhisperモデルは、モデルサイズが大きくなるほど高い精度が得られます。特に、最近large-v2モデルも公開されているようですので、さらなる精度を期待できますね。今回の検証は、Whisperのmediumモデルからは良さそうな精度を得ましたが、Macbook ProのPCではその以上の精度を期待するlargeモデルが正常に実行できないことは少し残念でした。また、モデルサイズの大きさや処理速度に大きく影響を与える問題を発見しました。モデルの初回ダウンロードのためサーバの立ち上がる時間が長い場合があるため、リアルタイム対応は複雑な対応になるかもしれませんが、短期間で音声認識にはGPUカードを搭載する高スペックなサーバーを検討するか有料版のWhisper APIおよびChatGPT　APIの利用を検討したほうがよさそうです。最近、OpenAIの有料版APIの導入により、1時間のミーティングをわずか3分で議事録を作成できるようになった記事が公開されましたので。 ChatGPT API (GPT-4)とWhisper APIの利用費用 今回のブログでは、Whisperの実行環境を自分で構築し、ChatGPT APIのtext-davinci-003モデルを使用して無料で音声自動要約システムを構築しました。しかし、より高性能なAPIであるGPT-4やWhisper APIを使用する場合は、以下の価格表に記載されている料金が必要となります。この価格表はOpenAIが正式に公開しているページに記載しているのでご参照くだだい。今回の検証音声ファイルの長さが30秒程度、生成したトークンが1000以内なので、GPT-4およびWhisper API(large-V2 モデル)を使うと１回の要約は$0.036（3/29現在のドル円は1$=131.5円で換算すると4.8円）になるかと思います。 モデルトークンタイプ価格GPT-4プロンプトトークン1000あたり$0.03サンプルトークン1000あたり$0.06GPT-4-0314プロンプトトークン1000あたり$0.03サンプルトークン1000あたり$0.06GPT-4-32Kプロンプトトークン1000あたり$0.06サンプルトークン1000あたり$0.12GPT-4-32K-0314プロンプトトークン1000あたり$0.06サンプルトークン1000あたり$0.12Whisper large-V2 モデル1分あたり0.006ドル まとめ いかがでしょうか？このブログでは、OpenAIが開発したChatGPT APIとWhisperを活用して、音声ファイルの自動要約方法を紹介しました。Whisperを使うことで、多言語の音声ファイルを文字起こしし、その後ChatGPTを使って、インタビューや議事録などのテキスト文章を簡単かつ迅速に要約することができます。ただし、Whisperの実験情報からわかるように、低いスペックなマシンではモデルサイズやサーバー立ち上がる時間、自動要約時間などの課題が残されています。特に、大規模な音声ファイルを短期間で処理するためには、有料版のAPIを使うか、もしくはGPUカード搭載サーバーでの実行が必要であると思います。今後は、この自動要約の機能をさらに便利なGUIに加えて、Slackなどのコラボレーションツールに組み込んで、議事録の作成作業を一層自動化することが期待できるのではないでしょうか？ 宣伝 グループ研究開発本部の次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットのいろんなアプリケーションの開発を行うアーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。

バイナリ互換性がないMySQLバージョン間（5.6→8.0）のDB移行が必要となり、DBを停止して、mysqldumpによるデータ移行を計画しました。その際にDBのダウンタイムをなるべく短くするため、インポートにかかる時間をパラメータチューニングによって短くできないか検証しました。 注意点 本記事の内容は、筆者の個人的な見解や認識に基づいて作成しているため、正確性、信頼性、完全性、最新性を保証するものではありません。 本記事は、2023/04/25 時点の情報をもとに作成しております。最新の情報については、他の情報源と照らし合わせてご確認ください。 今回紹介するパラメータはインポート時に一時的に設定するパラメータと仮定しており、運用時は適さないパラメータもあります。インポートが完了したら運用に適したパラメータへの変更をお願いします。 前提条件 インポートするデータ スキーマ毎にmysqldumpコマンドでダンプした、計14GBのダンプファイルダンプファイルはデータのみ（テーブル定義等は前もってリストア済み）テーブルのデータ型にはtext型・blob型も含まれているすべてのテーブルはInnoDBエンジンを使用ダンプファイルに「UNIQUE_CHECKS」「FOREIGN_KEY_CHECKS」を無効化しインポートするための記載がある VM情報（インポート先の情報） OSOracle Linux Server release 8.6vCPU4コアメモリ16GBディスクSSD 150GBMySQLバージョンmysql  Ver 8.0.28 for Linux on x86_64 (MySQL Community Server - GPL)DB構成シングル構成 インポート検証 インポート時間に大きな影響を与えそうなパラメータを変更して、検証を行いました。 時間を短縮することが見込めるため、並列でインポートを行いました。2並列から6並列までのインポートを検証したところ、4並列以上にするとスキーマ毎のインポート時間が増加するため、並列数は4並列としました。（vCPU、「innodb_write_io_threads」を増やしても同様の結果となったため、ディスクIOの限界によるものだと思われます） これより、各パラメータ紹介です。結論をお急ぎの方はこちら 変更しておくパラメータ（初めから固定しておくパラメータ） innodb_buffer_pool_size 動的、デフォルト：128MB メモリ領域であるバッファープールの値。インポート短縮に関わらず、一般的にチューニングをする必要がある。メインメモリの50～75%でよくチューニングされているため、今回は75%の12GBを設定している。 /etc/my.cnf ファイルにて、変更可能。 [mysqld] innodb_buffer_pool_size=12G 公式マニュアル[innodb_buffer_pool_size] innodb_log_buffer_size 動的、デフォルト：16MB ディスク上のログファイルに書き込みを行う際のバッファーサイズの値。バイナリログ・REDOログともにディスク上に書き込んているため、これらを有効にしている場合は影響があると思われる。 /etc/my.cnf ファイルにて、変更可能。 [mysqld] innodb_log_buffer_size=128M 公式マニュアル[innodb_log_buffer_size] max_allowed_packet 動的、デフォルト：64MB 1パケットの最大サイズの値。データ型として、blob型を扱っているため、念のため引き上げておく。 /etc/my.cnf ファイルにて、変更可能。 [mysqld] max_allowed_packet=1G 公式マニュアル[max_allowed_packet] 検証に使用するパラメータ（検証にて変更するパラメータ） innodb_doublewrite 静的（DB再起動が必要）、デフォルト：ON 二重書込みバッファを有効化・無効化する変数。二重書込みバッファはクラッシュリカバリの際に有益であるが、今回はパフォーマンスを重視するため、無効化する。 /etc/my.cnf ファイルにて、「skip_innodb_doublewrite」を設定することで無効化できる。 [mysqld] skip_innodb_doublewrite 公式マニュアル[innodb_doublewrite] innodb_flush_log_at_trx_commit 動的、デフォルト：1 コミット操作に対する厳密なACID特性とパフォーマンスのバランスを制御する変数。今回は、パフォーマンスを重視するため、各トランザクションのコミット後にログが書き込まれ、1 秒に 1 回ディスクにフラッシュされる「2」に設定する。 /etc/my.cnf ファイルにて、変更可能。 [mysqld] innodb_flush_log_at_trx_commit=2 公式マニュアル[innodb_flush_log_at_trx_commit] innodb_flush_method 静的（DB再起動が必要）、デフォルト：fsync（windowsの場合はunbuffered） データファイル・ログファイルへデータをフラッシュする際の方法を指定する変数。今回は、インポート時間の短縮を目的としているため、「O_DIRECT_NO_FSYNC」に設定。「O_DIRECT」も試してみたが、結果に差異は生じなかった。 /etc/my.cnf ファイルにて、変更可能。 [mysqld] innodb_flush_method="O_DIRECT_NO_FSYNC" 公式マニュアル[innodb_flush_method] log_bin 静的（DB再起動が必要）、デフォルト：ON バイナリログファイルへの書き込みを有効化・無効化する変数。レプリケーションを張っているような環境だと有効化が必須、今回はレプリケーションの想定はしていないため、無効化する。 /etc/my.cnf ファイルにて、「disable_log_bin」を設定することで無効化できる。 [mysqld] disable_log_bin 公式マニュアル[17.1.6.4 バイナリロギングのオプションと変数] Innodb_redo_log_enabled(ステータス変数) 動的、デフォルト：ON REDOログファイルへの書き込みを有効化・無効化する変数。REDOファイルは基本クラッシュリカバリの際に使用されるため、今回のように新しくダンプファイルからインポートを行う際は無効化できる。（データの用意が出来て、DBを運用する際は有効化する） 下記コマンドで変更可能。 ALTER INSTANCE [ ENABLE / DISABLE ] INNODB REDO_LOG; mysql> SHOW STATUS LIKE 'Innodb_redo_log_enabled'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Innodb_redo_log_enabled | ON | +-------------------------+-------+ 1 row in set (0.01 sec) mysql> mysql> ALTER INSTANCE DISABLE INNODB REDO_LOG; Query OK, 0 rows affected (0.01 sec) mysql> mysql> SHOW STATUS LIKE 'Innodb_redo_log_enabled'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Innodb_redo_log_enabled | OFF | +-------------------------+-------+ 1 row in set (0.00 sec) mysql> mysql> ALTER INSTANCE ENABLE INNODB REDO_LOG; Query OK, 0 rows affected (0.00 sec) mysql> mysql> SHOW STATUS LIKE 'Innodb_redo_log_enabled'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Innodb_redo_log_enabled | ON | +-------------------------+-------+ 1 row in set (0.01 sec) 公式マニュアル[15.6.5 redo ログ] その他のパラメータ innodb_write_io_threads 静的（DB再起動が必要）、デフォルト：4 データの書き込み時に使用されるI/Oスレッドの数。高速なストレージを使用している場合は、増やすことで高速化が見込める。今回は変更してもインポート時間に影響は見られなかったため、除外。（デフォルトのまま） 公式マニュアル[innodb_write_io_threads] bulk_insert_buffer_size 動的、デフォルト：8MB バルクインサート時に使用するバッファーサイズ。MyISAMへのインサートの高速化が期待できる。今回のテーブルはすべてInnoDBのため、この変数は検証対象から除外。 公式マニュアル[bulk_insert_buffer_size] 検証結果 パラメータ変更前パラメータ変更後5時間3分19分 5時間以上かかっていたインポートを20分以内に完了するまでに短縮できました。 ▼パラメータの変更前 innodb_doublewrite ON innodb_flush_log_at_trx_commit 1 innodb_flush_method fsync log_bin ON Innodb_redo_log_enabled ON # 検証にて変更しない変数（初めから固定で設定しておく変数） innodb_buffer_pool_size 12884901888 # 12GB innodb_log_buffer_size 134217728 # 128MB max_allowed_packet 1073741824 # 1GB ▼パラメータの変更後（最終値） innodb_doublewrite OFF # REDOログ無効化してるため変更しなくてもよい innodb_flush_log_at_trx_commit 2 # REDOログ無効化してるため変更しなくてもよい innodb_flush_method O_DIRECT_NO_FSYNC log_bin OFF Innodb_redo_log_enabled OFF # 検証にて変更しない変数（初めから固定で設定しておく変数） innodb_buffer_pool_size 12884901888 # 12GB innodb_log_buffer_size 134217728 # 128MB max_allowed_packet 1073741824 # 1GB パラメータ変更の順序と時間短縮の推移 順序パラメータ変更前変更後所要時間1パラメータ変更なしーー5時間3分2Innodb_redo_log_enabledONOFF24分3innodb_flush_methodfsyncO_DIRECT_NO_FSYNC22分4log_binONOFF19分5innodb_flush_log_at_trx_commit1219分6innodb_doublewriteONOFF19分 結果からの考察 圧倒的に時間短縮に影響が大きかったのは、REDOログの無効化でした。これにより、インポート時間が元の1割ほどまで短縮されました。（公式マニュアルでも新しくデータインポートをする際には無効化が推奨されており、無効化手順まで丁寧に書いてあるのはそういうことなんだろうと思います。もうむしろREDOログを無効化するだけでいいと言ってしまえそうです） バイナリログの無効化も影響はありましたが、REDOログと比べるとそこまでの影響はありませんでした。 「innodb_flush_method」に関しても、インポート時間への影響はあったものの、きわめて微小な影響でした。（わざわざ変更しなくてもよいかなと思うほどです）ただし、REDOログを有効化した場合のインポート時間短縮への影響は大きかったためディスクへの書き込み処理の量に依存しているだけで、インポート時間短縮への影響度は高いと思われます。 「innodb_doublewrite」に関しては、REDOログを無効化している状態では、暗黙的に二重書き込みは回避されるため、インポート時間への影響は見られませんでした。 「innodb_flush_log_at_trx_commit」に関しても、ログへの書き込み時の挙動の変更のため、REDOログを無効化している状態では、インポート時間への影響は見られませんでした。 まとめ REDOログを無効化するだけで、大幅に時間短縮できました。 さらに時間短縮を行いたいのであれば、「バイナリログ無効化」「innodb_flush_methodのチューニング」を試してみるとよいと思います。 「innodb_doublewrite」「innodb_flush_log_at_trx_commit」のチューニングはREDOログを無効化している場合では、効果はみられませんでした。 注意点でもふれてはいますが、戻す必要のあるパラメータは忘れずに戻すようにしましょう。 あとがき REDOログとバイナリログでここまで大きく影響に差が出ると思っていませんでした。MySQLのインポート試験では、より大きなデータを使って、明確なデータ型を設定して、データ型による短縮時間の差異を検証すべきです。しかし、今回は移行時間を短縮することに焦点を当てて、ダンプファイルのインポート時間短縮の検証を行いました。あくまで一例として、参考になれば幸いです。

本記事はGMOインターネットグループで複数ある開発者ブログのなかから人気の記事をピックアップして再掲載しています。機械学習や深層学習のビジネス応用を研究、社会実装をしているグループ研究開発本部 AI研究開発室のデータサイエンティストが寄稿した人気記事です。 モチベーション 2022年11月、 ChatGPT が登場したことにより、今の学生は AI にレポートを書かせるというような話が普通に出るご時世になりました。 ChatGPT は例えばプログラミングのお題を投げると AI がかなり高精度なプログラムを書いてレスポンスしてくれたりします。この技術は将来的に Google 検索を脅かす存在になるのではというほどの注目を集めています。 ペアプログラマー Github Copilot よりプログラミングに特化した AI サービスとして、 GitHub Copilot があります（ギットハブ コパイロットと読む）。2022年6月に正式リリースされています。このツールには以下のような特徴があります。 ソースの流れやコメントに合わせて次に書くべきコードをサジェストしてくれる。VS Code などの IDE とプラグインで連携できる。ChatGPT と同じく裏側に GPT ベースの AI を利用（GitHub は MS 傘下で、この GitHub Copilot も OpenAI の技術を採用）。AIの学習の元ネタはGitHub上に公開されているソースコード。有料（月額10ドル）。無料トライアル60日あり。 GitHub Copilot は優秀なペアプログラマーのように位置づけられており、生産性の向上効果は高く喧伝されています。公式サイトではある実装課題に対して2倍以上の速度改善効果があったと報告しています。 JSでWebサーバの処理を書いてもらう実験課題被験者数　　課題完了率　　　完了時間Copilotなし　　50人　　　　70%　　　　　　2時間41分Copilotあり　　45人　　　　78%　　　　　　1時間11分https://github.blog/jp/2022-09-15-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/ GitHub Copilot の詳細についてはググると様々な記事がヒットします。まだよくご存じない方は、まずは公式ページをご覧ください。https://github.com/features/copilot よし使ってみよう！となりました。 このブログでやりたいこと 「初めて NestJS を使いながらログイン画面のプログラミングをする。」 今回は GitHub Copilot を使いながら1つのシステムを構築してみて役に立った部分を書いていこうと思います。せっかくなので自分が知らない新しいフレームワークを勉強しながらやってみます。NestJS を選んだ理由は、チームの他のプロジェクトで利用されていて私も理解を深めたいと感じていたので選定しました。 結論ファースト 「コメント書け！」文脈や仕様情報がなければ GitHub Copilot はサジェストできない。コメントによりサジェスト精度が大幅に向上する。テンプレ的な import 文や config の実装は超得意GitHub Copilot にサジェストさせると一瞬で完了。GitHub Copilot からいいサジェストが来ないときまだコードの文脈が足りていない。または、コメントが悪い。ちゃんとロジックでやらせたい処理を一般的な技術用語で説明すること。まだ使いこなせなかった部分とはいえ、どんなにコメント書いてもまだ完璧に100点は難しかった。文法エラーや意図に反したコードは出るので、最後のレビュアーは人間。楽しい1人でググりながらサンプルを読んであれこれやるより、GitHub Copilot と一緒にプログラミングをしたほうがだいぶ早く実装が完了するし、何より楽しいです。 今回のルール VS Code で GitHub Copilot を使ってアプリケーションを実装する。ググりながら Web 上のサンプルコードを参照するが、コピペをしない。コードを手でタイプしていく。（AI によるサジェストが発生しやすい） 私の実装力 総合的に10段階中「6」ぐらいの実力です。Java, PHP は業務的にテックリードの経験もありますが、今回の課題 NestJS （ Node.js, Typescript をベースにしたフレームワーク）はほとんど経験がありません。サンプルコードをかじった程度なのでこの言語ではレベル2だと思ってください。 何を作るのか ユースケース 今回開発するのはログイン画面です。想定される使い方は以下のとおり。 ユーザがログイン画面を開く。ログイン画面でメアドとパスワードを入力してボタンを押す。サーバサイドでログイン判定をして完了画面へ遷移させる。 画面仕様 何の装飾もない簡素な画面を定義しました。 成功すると「ログイン成功」が表示されます。初学者の課題としてはド定番と思います。 フレームワーク フレームワークは NestJS を使いました。※今回は NestJS の詳細な解説は割愛させていただくため、もっと知りたいという方は公式ページをご確認ください。 NestJS 公式ページ：https://docs.nestjs.com/日本語訳：https://zenn.dev/kisihara_c/books/nest-officialdoc-jp 結果的にこんなファイル構成になりました。 src/ ├ main.ts ├ app.module.ts ├ app.controller.ts ├ app.service.ts ├ user/ │ ├ user.module.ts │ ├ user.controller.ts │ ├ user.service.ts │ ├ user.entity.ts │ └ dto/ │ └ user.post-login.dto.ts views/ └ user/ ├ login.hbs └ login-result.hbs 各ソースの役割をざっくり説明します。main.ts はフレームワーク的に最初に呼ばれる処理です。app.*.ts はHelloWorld時に生成されたベースアプリケーションです。Module 呼び出し部分の一部のみ使っています。user.*.ts がログイン画面の処理となっています。今回、私はこのuser.*.tsを GitHub Copilotと一緒に実装しました。 NestJS 上のクラスとしての役割 user.*.ts について、このクラスは何を担当してるの？というのが初見の方でもすぐわかるように少し説明しておきます。NestJS 上のクラスとしての役割は以下のようになっています。 Controller （user.controller.ts）コントローラ。リクエストを受け付けて返します。今回のURLは1つで、 http://localhost:3000/user/login です。また、リクエストパラメータのバリデーションを行います。複雑な処理はここでは書きません。後続の Service 処理を呼びます。DTO （Data Transfer Object）（user.post-login.dto.ts）リクエストパラメータを入れるオブジェクトです。今回は画面からEメールアドレスとパスワードを受け取ります。Service （user.service.ts）サービスは具体的な機能の処理を担当します。今回の処理は1つで、リクエストパラメータを DB へ問い合わせてログイン可能か判定します。Entity （user.entity.ts）データを保持するオブジェクト。データベースのテーブル定義どおりにパラメータを持ちます。今回は User テーブル1つの Entity を作成しました。ログイン処理時の Select 結果を保持します。Module （user.module.ts）サブシステムをまとめたものはモジュールと呼ばれます。上記のControllerやServiceなどが一式入ります。NestJS がアプリケーションを構成するために使用されます。View （login.hbs, login-result.hbs）画面。 Handlebars テンプレートエンジン（hbs）を使って描画します。 作っていく ここからがメインコンテンツです。開発の順序的には、DB接続設定、 Entity, Service, Controller, View の順に作成しました。 実装手順 第1ステップ　ベースプログラムをGenerateする第2ステップ　DB接続コンフィグを作成する第3ステップ　EntityクラスでDBのテーブルのデータを定義する第4ステップ　ServiceクラスでDBのテーブルをSelectする第5ステップ　ContorllerクラスでブラウザからURLへのリクエストを受け付ける第6ステップ　View の hbs で画面を表示する 第1ステップ　ベースプログラムをGenerateする NestJS ではコマンドによる Generate で Class の枠自体は一発生成できます。まず nest new project-name で Hello World のベースアプリケーションができます。 $ npm i -g @nestjs/cli $ nest new project-name 次にログイン画面の関連のモジュールの塊として user を生成します。 $ nest generate module user CREATE src/user/user.module.ts (82 bytes) UPDATE src/app.module.ts (386 bytes) $ nest generate service user ... $ nest generate controller user ... ここまではノーコーディングで完了。おかげで AI の出番はありませんでした。 第2ステップ　DB接続コンフィグを作成する ここから実装に入っていきますが、正直言ってしばらく失敗が続きました。（後半にうまくいきはじめます） ここではDB接続のライブラリ TypeORM をインストールして、Configを作成します。MySQL 8 はローカルにインストールしてあります。接続ドライバーには mysql2 を使いました。 % npm install @nestjs/typeorm typeorm mysql2 TypeORM では DB 接続情報を ormconfig.json ファイルに書きます。ここからVS Code上で実装します。 まず、結果的に仕上がったファイルはこちらです。 { "type": "mysql", "host": "127.0.0.1", "username": "root", "password": "root", "port": 3306, "database": "login", "entities": [ "src/entity/**/*.ts" ], "synchronize": true } 以下でどんな感じでAIが動いたかを書いていきます。 ついに初の AI サジェスト！ormconfig.json を書き始めて3行目でついに初めて GitHub Copilot によりサジェストされました。が、若干 ormconfig.json の正しい書き方と違うものが表示されてしまいました。（薄いグレーの箇所がサジェスト。上述の最終結果ファイルと比べると間違っていることがわかります） 気を取り直して一部を書き換えてゆっくり進めていくと次のサジェストが出てきます（同じくグレーの箇所。サジェストはタブを押すと確定されます）。今度はいいかんじですが、サジェストが数行一気に出てこず1行ずつだったのでAIもちょっと迷いながら出してきてるような印象でした。 ローカルの設定なのでDB名やパスワードなど違いはあるのですが、 typeorm ならこう書くでしょというセオリーがある程度出てくる感じではありました。 AIの精度が良くないようなことを書いていますが、あとから思い直すと、この段階で私はまだAIを完全に使いこなしているとは言えなかったと思います。 第3ステップ　EntityクラスでDBのテーブルのデータを定義する テーブル定義どおりのオブジェクト Entity を作ります。今回必要な user テーブルはログインのためにメアドをパスワードを保持する簡単なテーブルです。元の定義自体は私が考案しました。 user テーブル定義user_id int auto_incrementemail varchar 255password varchar 255created_at datetimeupdated_at datetime これをTypescriptで実装していきます。 まず結論として仕上がったファイルはこちらです。 import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm'; @Entity() export class User { @PrimaryGeneratedColumn() user_id: number; @Column() email: string; @Column() password: string; @Column() created_at: Date; @Column() updated_at: Date; } 書きあがるまでにどんな順序でサジェストされたかを書いていきます。まず User の Entity ならこれでしょ！というカラムがサジェストされました。（グレーの箇所）まだ私はクラス名ぐらいしか情報を教えていないのに。これはすごい。 ただ私は作成日 created_at 、更新日 updated_at を必ず用意するタイプなので、手で created_at を実装します。すると、 GitHub Copilot が updated_at をサジェストしてくれました。 ここまで書いてちょっとわかってきたのですが、コードの書き出し時にはAIのヒントとなる他のコードがないため雑なサジェストしかできないようです。ですが、コードが増えるにつれてその文脈をヒントにして精度の高いサジェストが出せるようになってきます。 第4ステップ　ServiceクラスでDBのテーブルをSelectする 前半は失敗が続いていましたが、このあたりからようやく成功しはじめます。ここでは Service クラスで DB アクセスしてユーザのデータを取得します。 結果的に書いたコードです。 import { Injectable } from '@nestjs/common'; import { InjectRepository } from '@nestjs/typeorm'; import { FindOneOptions, Repository, TreeRepositoryUtils } from 'typeorm'; import { User } from './user.entity'; import { bcrypt } from 'bcrypt'; @Injectable() export class UserService { constructor( @InjectRepository(User) private userRepository: Repository<User>, ) {} //Emailとパスワードを受け取り、ログイン処理を行う async login(email: string, password: string): Promise<boolean> { //Emailからユーザーを検索 let user = await this.userRepository.findOne({ where: { email: email } }); //ユーザーが存在しない場合はfalseを返す if( !user ){ return false; } //パスワードハッシュ比較 if( await bcrypt.compare(password, user.password) ){ return true; } return false; } } この完了までにどんなサジェストをもらえたか書いていきます。 まず、初期処理の Constructor です。NestJS では DB アクセスはフレームワークの Repository クラスが自動的にやってくれます。で、その設定を記述する Constructor のあたりはほぼ定型文なので GitHub Copilot がさらっと実装してくれました。ありがとう！ ですが、 User テーブルへのアクセスするためのコードで、なかなか意図したものをサジェストしてくれませんでした。（私は以下の findOne の箇所のパラメータを where: { email: email } としたいが、そうなってくれない）文脈的に email と password がパラメータとして流れてくる箇所なので、この2つのパラメータを使って Select をしようとする GitHub Copilot の提案はそんなにズレているわけでもないんですが、違うには違います。結局 fineOne の部分は私が自分で実装しました。実はこの問題は次のセクションで解決します。 最大の山場、パスワードハッシュ比較 Service の login ファンクションでは、 DB アクセスしてユーザのデータを取ったあと、ユーザが入力したパスワードが正しいかを検証します。User のテーブル内のデータはあらかじめ用意してあり、パスワードはあらかじめハッシュ化して保存してあります。ここでは何らかのロジックでパスワードのハッシュ比較をしたいなあと思いながら実装を始めました。 唐突に書き始めると、よくありがちなコードがサジェストで出てきましたが、これは違います。これはただの文字列比較です。ログイン処理らしくハッシュ化文字列を比較する実装を提案してほしいのに。 ～ ここでしばらくググる ～ bcrypt というライブラリでハッシュ化する例がいくつかあったので、これでハッシュ化パスワードの比較を行おうと思います。 ここで初めて私はコメントを書きます。import { bcrypt } from 'bcrypt'; を追加し、「パスワードハッシュ比較」というコメントを書きました。すると。。かなりそれっぽいコードが出てきました！import文＋コメントを書くことで仕様が明示され、まともな返しができるようになったのだと思います。そしてこれはほぼそのまま動作します。GitHub Copilot 優秀！ GitHub Copilot にいいコードを書かせようと思ったら、コメントでも前後のコードでもファイル名でもとにかく多くの仕様情報を伝えていく必要があることがわかってきました。 ひとつ前のパートで where: { email: email } がうまくサジェストされなかった問題がありましたが、これもコメント不足が原因でした。あとあとコメントを書き直して実装したらちゃんとサジェストされました！ 1行1コメント以上を徹底することですべてのコードを GitHub Copilot にサジェストさせることができる可能性があると感じています。AIとどうコミュニケーションするかを理解し実践していく時代が本格的にはじまったと言えるのではないでしょうか。 第5ステップ　ContorllerクラスでブラウザからURLへのリクエストを受け付ける ここでは2つのソースを作ります。1つ目はController で URL を制御します。2つ目はそのURLから送られるパラメータを入れる DTO を定義します。 まず、画面からSubmitされたパラメータを入れる DTO の最終形はこうなりました。 import { IsEmail, IsNotEmpty } from 'class-validator'; export class PostLoginDto { @IsNotEmpty() @IsEmail() email: string; @IsNotEmpty() password: string; } 以下 AI が提案してくれたコードです。 DTO は、ほぼほぼ GitHub Copilot が書いてくれました。 DTO にはバリデーションも含めることができ、リクエストパラメータのバリデーションチェック処理はデコレータで作れます（Javaでいうアノテーション）。 私はこのデコレータの使い方をあまり理解しないまま書き始めていましたが、GitHub Copilot がそれっぽいコードをサジェストしてくれたので、採用しました。（グレーの箇所がサジェスト） 次に Controller クラスは結果的にこうなりました。getLogin() : ログイン画面の初期表示。postlogin() : ログイン処理。Eメールとパスワードのパラメータを受け取って、Serviceにおくってログイン判定をします。 import { Controller, Get, Post, Render, UsePipes } from '@nestjs/common'; import { ValidationPipe } from '@nestjs/common'; import { Body } from '@nestjs/common'; import { PostLoginDto } from './dto/user.post-login.dto'; import { UserService } from './user.service'; @Controller('user') export class UserController { constructor (private readonly userService: UserService) {} @Get("login") @Render('user/login') getLogin() { return {message: 'ログイン画面'}; } @Post("login") @UsePipes(new ValidationPipe({whitelist: true, forbidNonWhitelisted: true})) @Render('user/login-result') async postLogin(@Body() postLoginDto: PostLoginDto) { let result = await this.userService.login(postLoginDto.email, postLoginDto.password); //Trueならログイン成功とレスポンスする if( result ){ return {message: 'ログイン成功'}; } return {message: 'ログイン失敗'}; } } AIの提案ですが、Service を呼ぶところの引数は GitHub Copilot がいい感じに提案してくれました。（グレーの箇所がサジェスト） 最後の Result を返す処理は、コメントを書いたら GitHub Copilot が期待通りに実装してくれました。 第6ステップ　View の hbs で画面を表示する View ではシンプルにメールアドレスとパスワードのパラメータを渡すForm画面を定義します。 結果的に出来上がったファイルlogin.hbs {{message}} <form action="http://localhost:3000/user/login" method="post"> email<br/> <input type="text" name="email" /><br/> password<br/> <input type="password" name="password" /><br/> <input type="submit" value="Login" /> </form> 唐突に書き始めました（もはや GitHub Copilot にとっては困る書き方）が、それっぽい FORM の提案をしてくれました。 Resultを表示するほうのページも載せておきます。（ド単純なのでサジェストはありませんでした。）login-result.hbs Result<br/>{{message}} まとめ　GitHub Copilot と仲良くやる方法 結論「コメント書け！」 テンプレ的な import 文や config の実装は GitHub Copilot にサジェストさせると一瞬で完了。複雑なビジネスロジック実装では、まずコメント書け！するとAIはサジェスト精度が大幅に向上。いいサジェストが来ないときは、コメントが悪い。書いてほしい処理を一般的な技術用語で説明すること。どんなにコメントを頑張ってもまだ完璧に100点は難しい。結構イージーな文法エラーがあったりする。1人でググりながらサンプルを読んであれこれやるより、AIのサジェストを活用したほうがだいぶ早く実装が完了する。まずやりたいことをコメントで書くと AI がとりあえず実装してくれる。それをベースにググると効率が良かった。 GitHub Copilot は良きプログラミングパートナーと言えるか？ 答えはYESです。GitHub Copilot は非常に有用でした。実際のコーディングでは上で紹介した内容の2倍以上がサジェストされています。体感的に以下の割合ぐらいのコードがサジェストされたと思っています。Entity 80%Service 80%DTO 90%Controller 80%View 90% 実装において定番の箇所は非常に多くあり、GitHub Copilot は定型文のサジェスト力は凄まじいです。実装初期段階でもこれ絶対 import するでしょっていうのを適切にサジェストしてくれます。独自ロジックの実装がいかに少ないかを改めて実感した次第です。ググる→コピペ→ちょっと修正、という従来の初学者の開発フローと比べても、気持ち的に全然早いと思いました。 AIコミュニケーションの時代に突入 とにかく一番大事なことはコメントをちゃんと書くことです。これによりサジェストの精度が大きく向上します。 使いはじめは正直よくわからんコードばかりがサジェストされて混乱し、なんでこんなことやってるのというのはありました。私が勉強不足なのか、そもそもGitHub Copilotがテキトーなのかと悩みましたが、コメントを書くことを覚えてからはこの問題はかなり少なくなったと感じています。問題はAIとのコミュニケーションのほうにあったわけです。 結果的に想像していた以上に楽しくプログラミングができました。今回 GitHub Copilot と一緒に書くことが結構楽しかったです。フレームワークに詳しくない分、こんな風に書けばいいんだというのをサジェストされるのは良い発見となりましたし、孤独な学習のツラさを忘れさせてくれるような心理的メリットもありました。 ただ、そもそもどういうコードを書くべきかという元のアイディアは、人間自身が持っている必要があると考えています。コードが正しいかどうかをレビューして最終的に判断するのは、現段階では人間だと思います。（これも覆される時代がおそらく来る） 懸念 現状の GitHub Copilot は業務利用における懸念もあるので、以下をメモ的に書いておきます。・実装したコードは必ず GitHub に送られるので、機密情報を含む場合はリスクを伴う。 AI 学習対象データから外すチェックボックスがあるので必ず OFF にするべき。・元ネタの学習データは GitHub にあるコード。そのためサジェスト時にはオープンソースライセンスの規約にのっとり引用元を明示するなどが必要だが、現状 GitHub Copilot にはできない（つまりライセンス違反の可能性がある）。公式では、2023年に、どのコードをもとにしたのか出す機能を提供予定としている。 最後に宣伝です！ グループ研究開発本部の次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットの新規サービスの開発を行うエンジニアを募集しています。募集職種一覧 からご応募をお待ちしています。

OracleとChatGPTを組み合わせて何か面白いことができないかと考え、データベース内に保存されたテーブル定義やレコードをChatGPTにインプットして様々な処理をさせるプロシージャを作成してみました。 作るもの こちらが今回作成するもので、スキーマ名とテーブル名、そしてそのテーブルに対して行いたい操作を入力すると、ChatGPTから回答が得られる作りになっています。 注意点、免責事項 本記事の情報は、筆者の個人的な見解や経験に基づくものであり、正確性、信頼性、完全性、最新性を保証するものではありません。本記事の情報やリンク先の内容によって生じた問題や損失について、筆者は一切の責任を負いません。本記事は予告なく内容が変更されることがあります。また、最新の情報については、他の情報源と照らし合わせて確認してください。利用者が本記事の情報に基づいて行った行為によって生じた損害について、筆者は一切の責任を負いません。 API経由とはいえ、データベース内部の情報をChatGPTへ渡しているため、本番データベースでの利用は想定しておりません。プロシージャで扱うデータには十分な注意を払ってください。 実行環境 OSDBAPEXORDSOracle Linux 7.6Oracle Database 19c22.223.1 準備 今回は、GUIで入出力の画面を作成したいという目的と、apex_web_serviceパッケージを使用する目的のためOracle APEXのインストールを行っています。 ChatGPT APIキーの入手やAPEX、Oracle RESTful Data Service（ORDS）のインストールが既に済んでいる方はテストテーブル作成まで読み飛ばしてください。 ChatGPT APIキーの入手 ChatGPTのAPIキーを入手していない場合、OpenAIにサインインし、以下のページ上にある「+ Create new sercret key」ボタンからsk-で始まる自身のAPIキーを入手してください。 https://platform.openai.com/account/api-keys ※APIキー流出によるセキュリティリスクにご注意ください。 Oracle Walletの設定 httpsでapiを実行するためには、接続先サーバのSSLサーバ証明書を検証するためのルートCA証明書が必要になります。 UTL_HTTPでHTTPS通信 / ORA-29024の回避 詳細については、上記の記事を参照してください。ここでは、コマンドのみを記載します。 ca-certificatesパッケージがない/古い場合は更新を行います。 # yum install ca-certificates 以降はoracleユーザで実行します。 Oracle Walletを作成 $ su - oracle $ ORACLE_WALLET_PATH=/opt/oracle/ca_wallet $ ORACLE_WALLET_PWD=WalletPasswd123 $ mkdir -p ${ORACLE_WALLET_PATH} $ orapki wallet create -wallet ${ORACLE_WALLET_PATH} -pwd ${ORACLE_WALLET_PWD} -auto_login ルートCA証明書を入手 $ cd ${ORACLE_WALLET_PATH} $ wget https://curl.haxx.se/ca/cacert.pem ルートCA証明書を変換 $ awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".pem"}' < cacert.pem Oracle WallletへルートCA証明書を追加 $ for i in /opt/oracle/ca_wallet/cert*.pem do orapki wallet add -wallet ${ORACLE_WALLET_PATH} -trusted_cert -cert "$i" -pwd ${ORACLE_WALLET_PWD} done Oracle APEXおよびOracle RESTful Data Serviceのインストール Oracle APEXインストレーション・ガイド リリース22.2 Oracle REST Data Services インストレーションおよび構成ガイド リリース22.2 Oracle APEXの環境作成(5) - APEXのインストール こちらも詳細な手順は公式ドキュメント含む、上記のリンクをご覧ください。 Oracle APEXのインストール 公式サイトから 2023/04/20 現在の最新版である22.2のzipファイルをダウンロードし、任意のディレクトリに配置して展開してください。ダウンロードするには、『Oracle APEX 22.2 - すべての言語』というリンクをクリックしてください。 $ mkdir /home/oracle/tools $ cd /home/oracle/tools $ unzip ./apex_22.2.zip 展開したディレクトリへ移動 $ cd /home/oracle/tools/apex 完全開発環境のインストール 今回APEXは、PDB [ORCLPDB1] に対してインストールしていきます。 $ sqlplus / as sysdba alter session set container = ORCLPDB1; APEXアプリケーションユーザおよびAPEXファイルユーザの表領域はSYSAUX、一時表領域はTEMP、APEXイメージの仮想ディレクトリは/i/としています。 @apexins.sql SYSAUX SYSAUX TEMP /i/ 日本語リソースのロード @load_trans.sql JAPANESE APEXインスタンス管理者アカウントの作成 @apxchpwd.sql 管理アカウント名はADMINのままで作成しています。 パスワードは6文字以上、1つ以上の数字、一つ以上の記号、1つ以上の小文字のアルファベットを含む必要があります。 Enter the administrator's username [ADMIN] User "ADMIN" does not yet exist and will be created. Enter ADMIN's email [ADMIN] Enter ADMIN's password [] *** APEX_PUBLIC_USERユーザをアンロックします。 alter user apex_public_user no authentication account unlock; 構成スクリプトを実行してRESTfulサービスを構成します。 @apex_rest_config.sql プロンプトが表示されたら、APEX_LISTENERアカウントおよびAPEX_REST_PUBLIC_USERアカウントのパスワードを入力します。 Enter a password for the APEX_LISTENER user: *** Enter a password for the APEX_REST_PUBLIC_USER user: *** Oracle APEXでWebサービスを使用するには、Oracle Databaseでネットワーク・サービスを有効にする必要があるため有効化を行います。 BEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host => '*', ace => xs$ace_type(privilege_list => xs$name_list('connect'), principal_name => 'APEX_220200', principal_type => xs_acl.ptype_db)); END; / Oracle RESTful Data Serviceのインストール rpmを用いたOracle RESTful Data Serviceのインストールの場合、jdkのインストールが行われないので別途インストールを行います。 $ sudo rpm -ivh https://download.oracle.com/java/17/latest/jdk-17_linux-x64_bin.rpm rpmでOracle RESTful Data Serviceをインストール $ sudo rpm -ivh https://yum.oracle.com/repo/OracleLinux/OL7/oracle/software/x86_64/getPackage/ords-23.1.0-9.el7.noarch.rpm 対話モードでセットアップ $ ords --config /etc/ords/config install 今回はPDBで動作させるため、データベース・サービス名にPDBのサービス名 [ORCLPDB1] を指定しています。また、APEX静的リソースの場所も [/home/oracle/tools/apex/images] と指定しています。 番号を入力して、インストールのタイプを選択します [1] データベースのORDSのインストールまたはアップグレードのみを実行する [2] データベース・プールを作成または更新して、データベースのORDSをインストール/アップグレードする [3] データベース・プールの作成または更新のみを実行する Choose [2]: 番号を入力して、使用するデータベース接続タイプを選択します [1] 基本(ホスト名、ポート、サービス名) [2] TNS (TNS別名、TNSディレクトリ) [3] カスタム・データベースURL Choose [1]: データベース・ホスト名を入力 [localhost]: localhost データベースのリスニング・ポートを入力してください [1521]: 1521 データベース・サービス名を入力してください [ORCLCDB]: ORCLPDB1 管理者ユーザー名を入力してください: sys SYS AS SYSDBAのデータベース・パスワードを入力してください: **** データベース・ユーザー: SYS AS SYSDBA URL: jdbc:oracle:thin:@//localhost:1521/ORCLPDB1に接続しています 情報の取得中. ORDS_METADATAおよびORDS_PUBLIC_USERのデフォルト表領域を入力してください [SYSAUX]: ORDS_METADATAおよびORDS_PUBLIC_USERの一時表領域を入力してください [TEMP]: 番号を入力して、有効化する追加機能を選択します: [1] データベース・アクション(すべての機能を有効化) [2] REST対応SQLおよびデータベースAPI [3] REST対応SQL [4] データベースAPI [5] なし Choose [1]: 番号を入力して、ORDSをスタンドアロン・モードで構成および起動します [1] ORDSをスタンドアロン・モードで構成および起動する [2] スキップ Choose [1]: 番号を入力して、プロトコルを選択します [1] HTTP [2] HTTPS Choose [1]: HTTPポートを入力してください [8080]: APEX静的リソースの場所を入力します: /home/oracle/tools/apex/images 2023-04-20T11:04:17.772Z INFO Oracle REST Data Services initialized Oracle REST Data Services version : 23.1.0.r0861423 Oracle REST Data Services server info: jetty/10.0.12 Oracle REST Data Services java info: Java HotSpot(TM) 64-Bit Server VM 17.0.7+8-LTS-224 完了後は上述のような出力が行われた後、Oracle RESTful Data Serviceが起動しますが、プロンプトが戻ってこないため一度Ctrl+Cで抜けます。抜けた後、再度systemctlで起動を行います。 Oracle RESTful Data Serviceの起動 $ systemctl start ords Oracle RESTful Data Serviceを起動したらAPEXワークスペースの作成を行います。 APEXワークスペースの作成 APEX管理サービスにサインイン サインインページは以下になります。 http://<ホスト名>:<ポート番号>/ords/apex_admin 今回はこちら。 http://localhost:8080/ords/apex_admin APEXインスタンス管理者アカウントのユーザ名とパスワードを入力してサインインします。 ワークスペースの作成 「ワークスペースの管理」 > 「ワークスペースの作成」 ワークスペース名に任意の名前を入れて次へ 今回は[ChatGPT_dev]という名前を付けました。 スキーマは新規で作成しています。 既存スキーマの再利用：[いいえ] スキーマ名：[APEX_CHATGPT_WS] 領域割り当て制限(MB)：[100] ワークスペース管理者の名前、パスワード、メールアドレスを入力します。 管理者のユーザ名：[APEX_CHATGPT_ADMIN] 管理のパスワード：[任意のパスワード] 電子メール：[任意の電子メールアドレス] 内容に問題無ければ「ワークスペースの作成」ボタンを押しましょう。 ワークスペースへサインイン 作成したワークスペースへサインインします。 http://<ホスト名>:<ポート番号>/ords 今回はこちら。 http://localhost:8080/ords ワークスペース名：[ChatGPT_dev] ユーザ名：[APEX_CHATGPT_ADMIN] 初回はパスワードの変更を求められるので新しいパスワードの入力を行います。 テストテーブルの作成 テストテーブルの作成 「SQLワークショップ」 > 「SQLコマンド」 からテストテーブルを作っていきます。 下記CREATE文を張り付け、「実行」ボタンを押してテーブルを作成します。 CREATE TABLE EMP (EMPNO NUMBER(4) primary key, ENAME VARCHAR2(10), JOB VARCHAR2(9), MGR NUMBER(4), HIREDATE DATE, SAL NUMBER(7,2), COMM NUMBER(7,2), DEPTNO NUMBER(2)) ; データの登録 続けてデータの登録を行います。 同様に以下のinsert文を貼り付け、「実行」を行います。 insert all into EMP values (7369,'SMITH','CLERK',7902,'1980/12/17',800,null,20) into EMP values (7499,'ALLEN','SALESMAN',7698,'1981/02/20',1600,300,30) into EMP values (7521,'WARD','SALESMAN',7698,'1981/02/22',1250,500,30) into EMP values (7566,'JONES','MANAGER',7839,'1981/04/02',2975,null,20) into EMP values (7654,'MARTIN','SALESMAN',7698,'1981/09/28',1250,1400,30) into EMP values (7698,'BLAKE','MANAGER',7839,'1981/05/01',2850,null,30) into EMP values (7782,'CLARK','MANAGER',7839,'1981/06/09',2450,null,10) into EMP values (7788,'SCOTT','ANALYST',7566,'1987/04/19',3000,null,20) into EMP values (7839,'KING','PRESIDENT',null,'1981/11/17',5000,null,10) into EMP values (7844,'TURNER','SALESMAN',7698,'1981/09/08',1500,null,30) into EMP values (7876,'ADAMS','CLERK',7788,'1987/05/23',1100,null,20) into EMP values (7900,'JAMES','CLERK',7698,'1981/12/03',950,null,30) into EMP values (7902,'FORD','ANALYST',7566,'1981/12/03',3000,null,20) into EMP values (7934,'MILLER','CLERK',7782,'1982/01/23',1300,null,10) select * from dual; さてこれでようやく準備が整いました。 プロシージャの作成 引き続きAPEXのSQLコマンドを利用して、プロシージャの作成を行っていきます。 プロシージャ内の変数 l_ora_wallet_path, l_ora_wallet_pass はOracle Walletの配置場所とパスワードを l_api_key は、ご自身で取得したChatGPTのAPIキーを入力してください。 プロシージャの処理の流れは以下の通りです。 引数 l_schema, l_table で指定されたテーブルの定義を取得上記テーブルのデータを最大100件取得1,2,で取得した内容と引数 l_request の内容をChatGPTのAPIへインプット引数 l_answer に格納されたChatGPTからの返答内容を表示 CREATE OR REPLACE PROCEDURE proc_chatgpt3_5( l_schema in varchar2, l_table in varchar2, l_request in clob, l_answer out clob) IS l_definition clob; l_record clob; l_answer_json clob; l_assistant clob; l_content clob; l_ora_wallet_path varchar2(200) := '/opt/oracle/ca_wallet'; l_ora_wallet_pass varchar2(200) := 'WalletPasswd123'; l_api_key varchar2(200) := 'sk-***'; l_url varchar2(4000) := 'https://api.openai.com/v1/chat/completions'; l_model varchar2(200) := 'gpt-3.5-turbo'; l_system varchar2(4000) := 'あなたは優秀なORACLEデータベースエンジニアです。'; l_eof varchar2(10) := '|EOF|'; l_eol varchar2(10) := '|EOL|'; CURSOR c_definition IS select owner, table_name, column_name, column_id, data_type, nullable from all_tab_columns where owner = l_schema and table_name = l_table order by column_id; l_defval c_definition%ROWTYPE; l_cols varchar2(4000); l_sql_stmt varchar2(4000); TYPE t_cursor IS REF CURSOR; c_record t_cursor; l_recval varchar2(4000); BEGIN OPEN c_definition; LOOP FETCH c_definition INTO l_defval; EXIT WHEN c_definition%NOTFOUND; IF l_definition IS NULL THEN l_definition := l_defval.owner|| l_eof || l_defval.table_name|| l_eof || l_defval.column_name|| l_eof || l_defval.column_id|| l_eof || l_defval.data_type|| l_eof || l_defval.nullable|| l_eol ; ELSE l_definition := l_definition|| l_defval.owner|| l_eof || l_defval.table_name|| l_eof || l_defval.column_name|| l_eof || l_defval.column_id|| l_eof || l_defval.data_type|| l_eof || l_defval.nullable|| l_eol ; END IF; IF l_cols IS NULL THEN l_cols := l_defval.column_name; ELSE l_cols := l_cols||'||'''|| l_eof ||'''||'||l_defval.column_name; END IF; END LOOP; CLOSE c_definition; l_sql_stmt := 'select '|| l_cols ||' from '|| l_schema ||'.'|| l_table ||' where rownum <= 100'; OPEN c_record FOR l_sql_stmt; LOOP FETCH c_record INTO l_recval; EXIT WHEN c_record%NOTFOUND; IF l_record IS NULL THEN l_record := l_recval|| l_eol ; ELSE l_record := l_record||l_recval|| l_eol ; END IF; END LOOP; CLOSE c_record; l_assistant := l_definition||'上記は「テーブル定義」です。列区切り文字は「'|| l_eof || '」、行区切り文字は「'|| l_eol ||'」、左から順にowner,table_name,column_name,column_id,data_type,nullableの情報になります。\n'|| l_record||'上記は「テーブルのサンプルレコード(最大100件)」です。「テーブル定義」のcolumn_id順に並び、列区切り文字は「'|| l_eof || '」、行区切り文字は「'|| l_eol ||'」です。'; l_content := '{"model":"'||l_model||'", "messages": [{"role":"system", "content":"'||l_system||'"}, {"role":"assistant", "content":"'||l_assistant||'"}, {"role":"user", "content":"'||l_request||'"}] }'; apex_web_service.g_request_headers(1).name := 'Content-Type'; apex_web_service.g_request_headers(1).value := 'application/json'; apex_web_service.g_request_headers(2).name := 'Authorization'; apex_web_service.g_request_headers(2).value := 'Bearer '||l_api_key; l_answer_json := apex_web_service.make_rest_request( p_url => l_url, p_http_method => 'POST', p_body => l_content, p_wallet_path => 'file:'||l_ora_wallet_path, p_wallet_pwd => l_ora_wallet_pass ); SELECT JSON_VALUE(l_answer_json, '$.choices.message.content') INTO l_answer FROM DUAL; EXCEPTION WHEN OTHERS THEN IF c_definition%ISOPEN THEN CLOSE c_definition; END IF; IF c_record%ISOPEN THEN CLOSE c_record; END IF; l_answer := 'error occurred.'; END; / エディタに張り付けて、「実行」を行います。 アプリケーションの作成 アプリケーションの作成 続いてプロシージャを動かすアプリケーションをAPEXで作っていきます。 「アプリケーション・ビルダー」 > 「作成」 > 「新規アプリケーション」 名前：[ChatGPT_APP] で「アプリケーションの作成」を行います。 ページの作成 次にフォームページを作成します。 「ページの作成」から レガシー・ページ タブ内にある「ローカル・プロシージャのフォーム」を選択し、「次」へ ローカル・プロシージャフォームの作成 ページ番号：[2] 名前：[ChatGPTプロシージャフォーム] で「次」へ ページ番号が2以外の場合、以降の手順に出てくる『P2_』という部分は、自身が使用したページ番号に読み替えて実行するように注意してください。 プロシージャの所有者：[APEX_CHATGPT_WS]ストアド・プロシージャ名：[PROC_CHATGPT3_5]フォームに含まれるプロシージャ引数の選択は以下のよう設定にします。 含める引数ラベルデフォルト表示タイプはいL_SCHEMAスキーマ名テキスト・フィールドはいL_TABLEテーブル名テキスト・フィールドはいL_REQUEST質問テキスト・フィールドはいL_ANSWER回答表示のみ 「ページの作成」ボタンを押して作成。 ページ・デザイナの編集 各フォームの機能を編集していきます。 アイテム Region Bodyから「P2_SCHEMA」を選択 右側のサイドメニューを以下の通り編集します。 設定 空白の切り捨て：[Leading and Trailing] テキストの大/小文字：[Upper] 外観 テンプレート：[Required - Above] 「P2_TABLE」も同じ設定へ変更します。 続いて「P2_REQUEST」を選択 右側のサイドメニューを以下の通り編集します。 外観 テンプレート：[Required - Floating] 最後に「P2_ANSWER」を選択 右側のサイドメニューを以下の通り編集します。 識別 タイプ：[リッチ・テキスト・エディタ] 設定 書式：[Markown] 読み取り専用 タイプ：[常時] ボタン ChatGPTにリクエストを投げるボタンを作成します。 Region Bodyから「P2_REQUEST」を右クリックし、「下にボタンを作成」をクリック 作成された「新規」ボタンの右側のサイドメニューを以下の通り編集します。 識別 ボタン名：[検索] ラベル：[検索] 外観 ボタン・テンプレート：[Text with Icon] ホット：[有効化] 動作 アクション：[動的アクションで定義] Region Bodyから「検索」を右クリックし、「動的アクションの作成」をクリック 「動的アクション」 > 「新規」 > 「True」 > 「表示」を選択 右側のサイドメニューを以下の通り編集します。 識別 アクション：[サーバー側のコードを実行] 設定 PL/SQLコード のアイコンをクリックしてコードエディタへ以下のコードを入力 (P2_部分はページ番号に合わせ適宜変更をしてください) BEGIN proc_chatgpt3_5(:P2_SCHEMA,:P2_TABLE,:P2_REQUEST,:P2_ANSWER); END; 送信するアイテム：[P2_SCHEMA,P2_TABLE,P2_REQUEST] 戻すアイテム：[P2_ANSWER] (P2_部分はページ番号に合わせ適宜変更をしてください) ChatGPTからのレスポンスにMarkdown書式が含まれていた場合、崩れて表示されてしまうため、ページを更新するアクションも作成します。 前段で作成した「サーバー側のコードを実行」を右クリックし、「アクションの作成」をクリック 右側のサイドメニューを以下の通り編集 識別 アクション：[JavaScriptコードを実行] 設定 コード欄に以下のコードを入力 location.reload(); 最後にトップの「ChatGPTプロシージャフォーム」をクリックし、ナビゲーション部分を以下の通り編集します。 ナビゲーション 保存されていない変更の警告：[無効化] 「保存」をしたら作成完了です。 動作確認 それでは動作確認を行っていきましょう。 ワークスペースのユーザで作成したアプリケーションへログインします。 http://localhost:8080/ords/r/chatgpt_dev/chatgpt-app サイドバーから「ChatGPTプロシージャフォーム」を開きます。 問題無く表示されたらいくつか質問をしていきましょう。 質問1 スキーマ名：[APEX_CHATGPT_WS]、テーブル名：[EMP] 質問：[このテーブルのレコード数を教えてください。またレコード数を取得するためのSQL文も教えてください。] 「検索」ボタンを押してしばらく待ちます。 回答： このテーブルのレコード数は14です。レコード数を取得するSQL文は以下の通りです。SELECT COUNT(*) FROM EMP;またはSELECT COUNT(1) FROM EMP;どちらのSQL文でも同じ結果が得られます。 期待した通りの回答が返ってきました。 ただ、同様の質問を別のタイミングでした時は以下の結果となりました。 ここでは「レコード数は、9件です」と誤った回答が行われました。 データをインプットしていても、完全な回答をしてくれるわけではないのですね。 次はもう少し複雑な質問にしてみます。 質問2 次はテーブルの正規化をしてもらいましょう。 スキーマ名：[APEX_CHATGPT_WS]、テーブル名：[EMP] 質問：[このテーブルの正規化を進めたいです。どのようにテーブルを分ければよいでしょうか。] 回答： まずは、このテーブルの中から、重複しているデータや、複数の値を持ってしまっている列を洗い出してみましょう。例えば、このテーブルの場合、部門情報が含まれておらず、部門IDが列に含まれているため、部門の情報を追加する必要があります。また、MGR列には、上司の社員番号が保存されていますが、これは従業員テーブル自身に従属的な列であり、繰り返しグループを持つため、別の従業員テーブルを作成する必要があります。したがって、従業員(Employee)テーブル、部門(Department)テーブル、上司(Manager)テーブルを作成する必要があります。また、テーブル定義には明示されていませんが、従業員に付随するプロジェクト(Project)情報がある場合や、従業員の役職(Position)情報がある場合は、それらも別のテーブルとして分離する必要があります。従業員テーブル:・従業員番号(Employee ID)・従業員名(Employee Name)・雇用日(Hire Date)・雇用形態(Job)・給与(Salary)・コミッション(Commission)・部門ID(Department ID)・上司ID(Manager ID)部門テーブル:・部門ID(Department ID)・部門名(Department Name)・場所(Location)上司テーブル:・上司ID(Manager ID)・上司名(Manager Name)・雇用日(Hire Date)・雇用形態(Job)・給与(Salary)・コミッション(Commission)・部門ID(Department ID) 上司テーブルが必要かはわかりませんが・・・正規化も行えるようです。 また、テーブル名やカラム名からこのテーブルが従業員の情報を記録したテーブルということも認識しているようです。 質問3 従業員テーブルであるということを理解しているようなのでカラム名を書かずに質問をしてみます。 スキーマ名：[APEX_CHATGPT_WS]、テーブル名：[EMP] 質問：[雇用されてから40年以上経過した従業員の一覧を教えてください。対象従業員の給与を10%アップさせるためのSQL文も教えてください。] 回答： 以下がSQL文になります。SELECT empno, ename, hiredate, sal FROM emp WHERE months_between(sysdate, hiredate)/12 >= 40; UPDATE emp SET sal = sal * 1.1 WHERE months_between(sysdate, hiredate)/12 >= 40;最初のSELECT文では、現在日から入社日までの経過月数を求め、年数に換算して40年以上働いている従業員を抽出しています。次にUPDATE文では、同じ条件で絞り込んだ従業員の給与を10%アップデートしています。 期待したSQL文は得られましたが、アウトプットの量を減らすためか一覧は出力されませんでした。 質問4 最後は結合をさせてみます。 スキーマ名：[APEX_CHATGPT_WS]、テーブル名：[EMP] 質問：[従業員と上司の名前を並べて表示してください。またその時使用するSQL文も教えてください。] 回答： 次のSQL文を使用して、従業員と上司の名前を並べて表示することができます。SELECT e.ename AS employee_name, m.ename AS manager_name FROM emp e LEFT JOIN emp m ON e.mgr = m.empno ORDER BY m.ename, e.ename;このSQL文では、JOINを使用して従業員表(emp)を上司表(emp)と結合することにより、従業員と上司の名前を表示します。ORDER BYを使用して、上司の名前、従業員の名前の順でソートされます。また、LEFT JOINを使用しているため、上司がいない(社長である)従業員の名前も表示されます。 正しいSELECT文が返ってきましたが、こちらもアウトプットの量を減らすためか「従業員の名前と上司の名前を並べて表示してください」については無視されてしまいました。 おわりに 今回はある程度意図した回答を得られたときのサンプルを記載しておりますが、完全に誤りのない情報を得ることは難しいようで、不正確なレコード数や不正確な合計値を返してくることもありました。 得られる結果に注意を払う必要はありますが、適切に活用すればデータベース設計やアプリケーション開発に大きな貢献をしてくれる可能性を感じさせてくれる結果となりました。 Oracleの機能として大規模言語モデルが提供される日も近いかもしれませんね。 参考サイト http://apexugj.blogspot.com/ https://yaitcon.hashnode.dev/explain-view-sql-via-chatgpt-with-plsql https://cosol.jp/techdb/2015/12/https_using_utl_http_how_to_aviod_ora-29024/

Perlを中心としたIT関連カンファレンス「YAPC::Kyoto  2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワソン君」』をお届けします。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームフォームグループ SRE https://speakerdeck.com/ryuichi1208/ru-men-zhang-hai-dui-ying GMOペパボの古参サービスを支える技術部プラットフォームグループ 今回講演した渡部が主に担当しているサービスは、ネットショップ作成・運営のためのプラットフォームである「カラーミーショップ」です。2005年にサービス提供を開始した古参サービスで、流通総額は1兆円を超え、比較的大きなトラフィックを有するサービスです。 カラーミーショップのサービスの特徴やサービス構成は、「CI/CD Conference 2023 by CloudNative Days」（https://developers.gmo.jp/30849/）でもご紹介しているので、そちらも参考にしてください。 そんなカラーミーショップをはじめとしたGMOペパボのサービスにおいて、渡部が所属する技術部プラットフォームグループが担当しているのは、「サービスの多様性を確保し、サービスの成長に合わせて適切な環境を提供する」という点だと渡部は言います。具体的にはサーバーの調達、キッティング、SREによるサービスレベルの向上、クラウド環境の検証や選定、専門事業部門のアプリケーションの改善・開発など、事業の成長を支えることを目指しています。 障害対応における5つのフェーズ そんなGMOペパボにおける障害対応フローが今回のテーマです。 渡部はまず、サービス障害の定義として「通常の運用状態から逸脱してユーザーに影響を与える事象」と位置づけます。これはシステムの異常動作やアプリケーションの問題などが該当します。 それに対する「障害対応」とは、「サービス障害が起こった状態から通常の運用状態に戻すための対応」ということになります。 この障害対応を、渡部は5つのフェーズに分類します。 （1）障害の影響範囲の特定と分類 まずは提供範囲の特定が重要になります。使えない機能は何か、例えば外形監視が落ちている場合はどこに影響があるかを評価し、分類します。その結果、問題解決に必要な情報を集めることができ、影響範囲が分かれば、原因特定の方針決定の根拠となる情報も得られると言います。 （2）関係者への連絡 続いて、ユーザーに対してどのような影響があるのかを、関係者に周知することが重要だと渡部は指摘します。障害発生時は技術的な話をしがちですが、最初にやるべきはユーザーへの影響がどの程度あるかを共有することで、「報告は結論ファーストを意識している」と渡部。 同時に、サービスに関わる様々なチームへの連絡も行います。渡部の所属するSREチーさまざまは障害アラートなどを出しますが、障害の復旧がすべてできるわけではありません。そのため、マネージャーやカスタマーサポートチームに連絡して協力を仰ぐこともあるそうです。エンドユーザーに対して影響がある障害であれば、SNSなどでのアナウンスも必要になるので担当者と共有をします。 障害を起こしたアプリケーションに精通しているメンバーが、常に障害のアラートを受け取れるわけではないため、その場合はアプリケーションエンジニアに、セキュリティインシデントならセキュリティエンジニアにエスカレーションすることもあるそうです。 （3）原因調査 3番目が「なぜ繋がらないのか」を調べるフェーズです。「外形監視になった」、「Webサービスに繋がらなくなった」というだけでは、「なぜ繋がらないのか」の原因は分かりません。 最も頻度が多いのは、サービスに何かしらの変更を加えた際に繋がらなくなるエラーが起きることだと言います。そのため、まずは変更したシステムを調べることになります。 例えば、アプリケーションをデプロイした場合はその内容を確認したり、GUIの設定画面からサーバーの設定を変更していたらそれを確認したりします。とはいえ、「何もしていないのに壊れるケースが"たまによくある"」と渡部は苦笑します。 他にはハードウェアが原因の場合や急激なトラフィックでソフトウェアが耐えきれない場合があるので、もう少し詳しく原因を探っていくそうです。サービスを構成するコンポーネントから、怪しい部分を探るわけです。 原因調査は、仮説確認を繰り返していくフェーズだと渡部は話します。どこが怪しいのか全くわからない状いであれば、例えば構成図を見てロードバランサーやWebアプリケーション、データベース、ネットワーク、外部連携サービスなど、何かおかしくなっていないかを見ていきます。 渡部が取る手法としては「挟み撃ち法」があるそうです。これは、例えばL3レイヤーを調べたらL7のWebアプリケーションを確認し、L4を見てL6を見る、というような順番で確認していく方法です。「OSI参照モデルをイメージしてもらえれば分かりやすい」と言います。 このフェーズではログ調査も行って、怪しいログをチェックすることもしています。 （4）復旧作業の実施 原因が判明したら復旧作業を実施します。これには2つのパターンがあり、一つ目が「根本対応」です。調査で原因が完全に判明すれば根本的な対応が行えます。ところが、原因は分からないけれども接続できないということもあります。 そうした場合に行うのが「止血対応」と呼ばれる作業です。過去の知見から、「もしかしたら復旧するかもしれない」という対応手段を試していくというものです。ここで大事なのが、「原因が分からなくてもユーザーが正常にサービスを利用できる」ことを最優先にするということです。そのため、まずは止血対応によってサービスを正しい状態にすることを意識しているそうです。 具体的な手法としては、OSやミドルウェアの再起動、アップデートをしていたら根本原因が分からなくてもロールバックするといった手段で復旧を試みます。急激なトラフィック増加等があればリソース不足の可能性もあるので、スケールアウトなどの対応をします。 （5）ポストモーテム 最後のフローがポストモーテムです。これは障害対応後に行われる反省と改善のための分析会議」で、障害の原因、障害対応の振り返りを行うことで、今後の改善点を見つけることを目的としています。 こうした会議でありがちなのが、失敗の要因を明確にすることだけになってしまい、成功の要因が明らかにならないという例があります。そこで渡部は「対応がなぜうまくいったのか」という要因を分析してドキュメント化も行っているそうです。 この会議のドキュメントは、会議に未参加のチームや、今後参画する新メンバーも学んでいけることを意識して執筆していると言います。具体的にはなぜこうした対応をしたのか、障害復旧後にアクションアイテムがあったらイシュー化して追跡しやすくする、といった記録を残していると言います。 1人に頼らずメンバー全員の能力向上を こうした障害対応の能力をどのように向上させるか。渡部はまず「障害対応能力」について、前述の5フェーズを全て1人で担当できるという人物が能力値マックスと規定します。 そもそも障害をゼロにすることはできないという判断から、障害が発生したときに対応するメンバーの能力向上が必要というのが渡部の考えです。そのためには「何度でも障害に向き合っていく必要がある」と渡部は言います。 以前まで、GMOペパボでも障害発生時に一部の優秀なエンジニアが1人で原因特定から復旧までを短時間で対応してしまい、他のメンバーの知見が残らないということがあったそうです。 そういった優秀なエンジニアも24時間365日稼働できるわけではないので、そのエンジニアがいないときの障害対応の時間が長くなってしまい、サービスの信頼性低下にも繋がりかねません。 そのため、障害対応能力が高いメンバーがチーム内に多く存在するほど、サービスの信頼性向上に繋がる、というのが渡部の考えです。 そうしたメンバーを増やすためには、障害対応の教科書のような書籍を学習するだけで実践するのは難しいといいます。例えばサービスの再起動をするためのコマンドは学べても、どのタイミングで、どういった根拠で再起動をするのか、といった見極めは経験が必要だからです。もちろん、本番環境で学ぶのが一番なのですが、それが難しい場合もあります。 2つの施策で能力向上 渡部が採用した施策は2つ。Playbookの作成と障害対応訓練です。 Playbookとはアメリカンフットボールの用語で、戦略やプレイをまとめた資料です。渡部は「一定の知見や経験を持った人でなければ理解できない熟練者向けのドキュメント」と位置づけます。渡部のチームでは、障害対応能力の高いメンバーが行った作業内容と、その作業に至った思考の流れをドキュメント化しているそうです。 これまでのドキュメントには事実は記載されていましたが、具体的な対応方法の記載がありませんでした なぜそのコマンドを打ったのか、なぜその作業を行ったのか、結果として何が起きたのか、そういった部分を取りまとめることで、他のメンバーの障害対応能力向上に繋がると考えたと言います。 PlaybookはMarkdownによって事例ごとに情報を蓄積していきます こうしてPlaybookに事例を積み上げて情報を共有し、メンバーのノウハウを蓄積していくことに加えて、障害対応経験を増やすための訓練も行います。 過去に発生した障害などをテスト環境に再現して、実際に調査から復旧までを実践してもらう内容ということで、さらに出題者と回答者に分かれて実施しているそうで、机上演習のようなものというイメージのようです。 Playbookと障害対応訓練という施策を実施した結果、「チーム全体の障害対応能力の向上に繋げることができた」と渡部は言います。調査から復旧までを単独で実施できるメンバーも増えているそうです。訓練で実施したトレーニングと同じ障害が、訓練の数時間後に実際に発生する、といったこともあったそうで、訓練を生かすこともできたと言います。 障害対応も一日にしてならず 「障害を完全になくすことはできない」。まとめとして渡部はそう伝えます。そのため、障害は起きるものとして対応に向き合う必要があります。優秀なメンバーだけが対応するような属人的な状況は危険で、障害対応できるメンバー数を可視化していく必要があるとしています。 障害対応できるメンバーを増やすためのPlaybookや障害訓練といった施策も、すぐに効果が出るような施策ではなく、渡部は「ローマは一日にしてならず、障害対応も一日にしてならず」として、継続的に続けることが必要だと強調しました。 質疑応答では、Playbookを作成するためのコストの問題について問われ、渡部は「コストはかかるけれど、最終的にメンバーが増えるというチームの状況だったので、それでペイできるという判断で未来への投資としてメンバーを説得しました」と回答。ちなみにPlaybookには「障害対応での思考の流れをドキュメント化する」という例を挙げた渡部ですが、これは作業中にSlackのスレに書き込んでいって、最後にまとめるそうです。 障害対応訓練に対して問われた渡部は、「簡単なものだと30分や1時間で障害環境を用意して、回答を受ける側も1時間程度で終わる」とのことで、極端に長時間化かかるような訓練はまだしていないということです。逆に言えば、それでも訓練としては意味があるということと言えそうです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=JsfhvMffnHk

2023年3月23日（木）〜25日（土）に技術カンファレンス「PHPerKaigi 2023」が練馬区立区民・産業プラザ Coconeriホールおよびオンラインにて開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛し、登壇セッションでは、GMOペパボ株式会社より小山 健一郎が登壇しました。その内容をご紹介します。 はじめに テスト戦略を策定する際の指針となるコンセプトの1つに「テストピラミッド」があります。テストピラミッドでは、ユニットテスト、インテグレーションテスト、E2Eテストの3つのレベルに分けて、この順でテストの量を小さくしていくピラミッド型にすることが推奨されます。一方で、React Testing Libraryの作者であるKent C. Dodds氏は「テスティングトロフィー」というインテグレーションテストに最も重点をおいたテストコンセプトを提唱しています。複数の選択肢があるなか、テスト構成の最適解はどのように考えていけばよいのでしょうか。2023年3月23日（水）〜25日（土）に練馬区立区民・産業プラザ Coconeriホールおよびオンラインにて開催された技術カンファレンス「PHPerKaigi 2023」で、GMOペパボ株式会社 小山 健一郎氏が自社での事例をもとに解説しました。 登壇者 小山 健一郎　＠k1LoWGMOペパボ株式会社 技術部 技術基盤チーム https://speakerdeck.com/k1low/phperkaigi-2023 テストピラミッドとテスティングトロフィーの違い 小山氏は、講演冒頭で単体テストの原則とそのパターンをまとめた書籍『単体テストの考え方/使い方』（マイナビ出版、2022年）を紹介しました。同書籍によると、テストピラミッドは、テスト・スイートにおいて、「単体テスト（ユニットテスト）」「統合テスト（インテグレーションテスト）」「E2E（エンドツーエンドテスト）」という異なる種類のテストがそれぞれ特定の割合でテストケースを持つようになっていることを提唱している概念とされています。そして、テストピラミッドの横幅は、テスト・スイートを構成する各種類のテストに含まれるテストケースの数を示します。そのため、テストピラミッドの層が横に長いものほど、テストケースが多いことになります。また、テストピラミッドの高さは、対象のテストがどれくらいエンドユーザーの視点に近いのかを示します。 一方で、テスティングトロフィーでは、テストの構成割合がテストピラミッドとは異なります。横幅をみると、インテグレーションテストが最も大きくなっており、重点的にインテグレーションテストを実施することが推奨されます。小山氏は「信頼性と速度・コストのトレードオフのバランスを上手くとっている、インテグレーションテストに労力を費やすと効率よくテストが進められるという主張だと考えられる」と説明します。 テストの分類 そもそも、ユニットテスト、インテグレーションテスト、E2Eテストには厳密な定義がなく、人によって認識がずれてしまうことも多くあります。ここで小山氏はそれぞれの考え方を次のように整理します。 「『単体テストの考え方/使い方』によると、ユニットテストは1単位の振る舞いを検証すること、実行時間が短いこと、他のテストケースから隔離された状態で実行されることという3つの性質を持つ。これら3つのうち1つでも損なっているものをインテグレーションテストに分類する。ただし、この定義でもすべてが明確になるわけではなく、“隔離された状態”についても解釈の異なる考え方がある」（小山氏） ここで、小山氏はテストの実行速度と決定性に着目したテスト分類としてテストサイズを取り上げます。これは『Googleのソフトウェアエンジニアリング』（オライリージャパン、2021年）で紹介されているテスト分類です。書類を元に小山氏は、テストサイズの定義を下記のように紹介します。 スモールテスト:単一プロセス（シングルスレッド）内で実行されるもの。sleep、I/O、ブロックは禁止ミディアムテスト:単一マシン内で実行されなければならない。ローカルホスト以外のシステムへのネットワーク呼び出しは禁止ラージテスト:複数マシンにまたがるテスト よりわかりやすくするためにテスト対象のアプリケーションを具体的に示したうえで考えると、テストサイズは図のようなイメージとなります 「良いテスト」とは？ 『単体テストの考え方/使い方』では、以下の項目が良いテストを構成する4本の柱とされています。 退行（regression）に対する保護リファクタリングへの耐性迅速なフィードバック保守のしやすさ ただし、1〜3は互いに排反する性質であり、すべてを成り立たせることはできません。こうした制約のなかでは、リファクタリングへの耐性と保守のしやすさを可能な限り備えたうえで、リファクタリングへの耐性と迅速なフィードバックの2つのあいだでバランスを調整するのが現実的な戦略となります。 ここで、テストサイズの観点からテストピラミッドのテスト戦略を捉え直してみます。退行に対する保護は、ラージ＞ミディアム＞スモールとなりますが、保守にかかるコストが増加するほか、迅速なフィードバックは得られません。したがって、保守コストと迅速なフィードバックを考えると、テストケースの数は、スモール＞ミディアム＞ラージという戦略になります。 一方、テスティングトロフィーをテスト戦略で捉え直すと、信頼性が重要視されるため、品質保証、つまり退行に対する保護を優先します。結果、ラージ＞ミディアム＞スモールの順でテストの信頼指数（品質保証への貢献度）は高くなりますが、ラージを重視すると迅速なフィードバックが得られません。そこで、バランスの良いミディアムテストに重点を置くという考え方になります。 小山氏は「テストピラミッドは、ほとんどのアプリケーションに効果を発揮する構成だが、それがすべてではない。良いテストを構成する4つの柱と、テスト対象の状況やフェーズ、開発体制などさまざまなパラメーターをみて判断していくことが重要」とします。 GMOペパボの事例に見る、テスティングトロフィー実践の課題と解決策 ここから小山氏はGMOペパボでの事例をもとに、テスト構成の方針の立て方について解説していきました。 今回対象となったのは、新規開発のAPIサーバです。扱うドメインはシンプルで、ドメインロジックもあまり複雑ではありませんが、データの取り扱いを慎重に行う点、また長期運用が想定されている点に気をつける必要がありました。動作環境はコンテナベースを想定しており、開発言語はGo、APIの定義にはOpenAPI Spec v3を採用しスキーマ駆動開発で進める方針となっていました。 小山氏によると、アプリケーションのテスト戦略を考えたのは開発初期だったといいます。当時は開発言語が決まったくらいの時期で、アプリケーションの実装が見えてこないことによる難しさがありました。 特に今回は、長期運用に耐えうることが要件に盛り込まれていた点がポイントでした。これを意識し、「まず外部とのインターフェイスであるAPIスキーマが重要。接点がある以上は、APIの更新がありつつも残るはず。データベースの寿命はアプリケーションよりも長いと考えられるため、データベースのスキーマも大事」（小山氏）と方針を決めていきました。小山氏は「一方で、アプリケーションのアーキテクチャが長期的に持続するかわからない、アーキテクチャの検討もできていない状況で、自分が今から設計するアプリケーションそのものが信用できない状態だった」と振り返ります。 ここで有効となるのが、テスティングトロフィーの考え方です。アプリケーションの外部からのテストに重点を置くことで、アプリケーションの実装の変化に影響されにくいテスト構成にするというアプローチを取ることができるためです。ただ、実現にあたっては大きな課題がありました。ミディアムテストのコストがスモールテストに比べて大きいという問題です。 まずは、テストの実行コストです。迅速なフィードバックの観点からすると、一般的にミディアムテストはスモールテストより実行時間が長くなるため、「並行実行の仕組みで緩和しつつも、ある意味許容する必要があった」と小山氏はいいます。また、テストの作成保守コストも課題です。「APIにHTTPリクエストを送信して、意図した結果や状態になっているかを確認する」というテストを書くこと自体に手間が掛かってしまうため、できる限り簡単に書ける仕組みを構築することが求められます。 この解決策としてのがrunnというツールです。runnは、シナリオに沿って操作を自動化できるパッケージ/ツールで、HTTP、gRPC、データベースをはじめさまざまなプロトコルに対応しています。 シナリオファイル（YAML）のフォーマットは、OpenAPI Specライクであり、シナリオ内のステップ間の値が自動で連携されるので、「ステップAを実行してからその結果を使ってステップBを実行する」というシナリオを構築しやすいといえます。分割実行、サンプリング実行、ランダム実行、並行実行なども可能で、ループ実行やリトライ実行の仕組みも組み込みで備わっています。 runnでは、1つのシナリオは1つ以上のステップから構成されており、1シナリオは1YAMLファイルになっています。これをランブックと呼びます。シナリオごとにランナーと呼ぶステップ実行コンポーネントを定義し、ランナーを使って各ステップを実行していくというアーキテクチャになります。 「ログインしてプロジェクト一覧を取得する」というシナリオは以下のとおりです。ランナー、変数を設定して、各ステップを書いていくという流れになっていることがわかります。 このように、ミディアムテストの課題であったテストの作成保守コストは、runnでスモールテスト並みに削減することができました。 「テスト構成の最適解はテストピラミッド一択ではない」 テスティングトロフィーを実践してみて「あくまで主観だがうまくいった」と振り返る小山氏。具体的な効果について次のように紹介しました。「1つのシナリオあたりのコードカバレッジが非常に大きいので、リファクタリングへの耐性、退行に対する保護への効果が大きい。シナリオの拡充もYAMLを書くだけでよいためかなり捗る。また、シナリオがOpenAPIライクだったので、エンジニアにとって読みやすいものになり、オンボーディングにも役立つ」（小山氏） 今後の規模拡大やアーキテクチャの安定化などの要因によってテスト構成がピラミッドに近づいていくことは大いにありうるといいますが、小山氏は「現時点においては（テスティングトロフィーの採用は）悪くない判断だった」と評価します。そのうえで「テスト構成の最適解はテストピラミッド一択ではない。その都度、状況にあわせて考えていきたい」と語りました。

　今、何かと話題のChatGPTですが、OpenAIがAIサービスのAPIを公開しています。こちらを利用して、Power AutomateとTeamsを組み合わせてチャットボットを開発してみましょう。今回はAzure Automationの検証も兼ねてクラウド上でPowerShellからOpenAIのAPIにアクセスします。　クラウド上で実行されるPower AutomateのクラウドフローではPowerShellを直接実行することができません。クラウドフローからPower Automate for desktopのデスクトップフローを呼び出して実行する方法がありますが、呼び出す先のPCが起動している必要があります。Azure Automationを利用してPCが不要のいわゆるサーバーレスでPower Shellを実行する方法を紹介します。 動作環境 Power Automateのプレミアムコネクタを使用しています。Azure Automation を利用するためのAzureサブスクリプションが必要です。Azure Automationは一定範囲内であれば無料で利用可能です。参考：料金 - Automation | Microsoft AzureOpenAIのAPI無料利用枠（18ドル分）を使用しています。 Azure Automation Azure Automationはクラウド上のタスクを自動化できるサービスです。Azure Automation のRunbookを利用すると、通常はPCやサーバー内で実行する必要があるPowerShellやPythonのスクリプトをサーバーレス（クラウド上）で実行することが可能です。 早速、Azure Automationの設定を行い、実際に動作確認をしてみましょう。 Azure Portalにログインして「Automation アカウント」を検索してアカウントを作成します。 左メニューの「プロセスオートメーション」-「Runbook」から「Runbookの作成」を選択します。 以下の内容で作成します。 簡単なコマンドを入力して「保存」を選択します。「テストウィンドウ」を選択します。 「開始」を選択して実行します。「ジョブストリームを更新します」を選択すると実行結果が表示されます。米国時間で表示されました。Azure Automationを利用してPowerShellを実行できることが確認できました。 PowerShellのコード作成 　今話題の「ChatGPT」と同様にOpenAIがAIサービスのAPI を提供しています。PowerShellから呼び出してチャットボットとして利用してみましょう。事前準備として、OpenAIにサインアップして無料アカウントを作成します。 API Keyを作成して取得します。 今回実行するコードはこちらです。入力されたテキスト内容に対してAI APIが回答をしてくれます。Paramで引数を設定することで、Runbook実行時に値を渡すことができます。 Param ( [String]$GetText ) $Uri = "https://api.openai.com/v1/completions" $Headers = @{ "Content-Type" = "application/json" "Authorization" = "Bearer <取得したAPIキー>" } $Body = @{ "model" = "text-davinci-003" "prompt" = $GetText "temperature" = 0.7 "max_tokens" = 2000 } | ConvertTo-Json $Byte = [System.Text.Encoding]::UTF8.GetBytes($Body) $Response = Invoke-RestMethod -Uri $Uri -Method Post -Headers $Headers -Body $Byte $Utf8_Text = $Response.choices[0].text $Output = [System.Text.Encoding]::Utf8.GetString([System.Text.Encoding]::GetEncoding("ISO-8859-1").GetBytes($Utf8_Text)) $Output Azure AutomationでRunbookを作成して実行してみましょう。 「パラメーター」に“今日の東京の天気は？”と入力して実行します。 このようにAI APIから回答が届きます。 最後に「公開」を選択してPower Automateから利用できるようにしておきます。Azure Automationの準備は以上で完了です。 Power Automate クラウドフローの作成 最後にAzure Automationを利用するためのクラウドフローを作成します。 フローの全体はこちらになります。Teamsのチャネルに投稿されたメッセージをRunbookのパラメーターとして引き渡して、AI APIから回答を取得します。各変数は「ジョブの作成」-「Runbook Parameter GetText」　＝　“チャネルに新しいメッセージが追加されたとき”-“メッセージ本文コンテンツ”「ジョブの出力を取得します」-「ジョブ ID」 ＝ “ジョブの作成”-“ジョブID”「チャネル内のメッセージで応答します」-「Message ID」 = “チャネルに新しいメッセージが追加されたとき”-“メッセージ ID”「チャネル内のメッセージで応答します」-「Message」 ＝ “outputs('ジョブの出力を取得します').body”以上となります。 テスト実行 Teamsでチャットボットをテストしてみましょう。簡単な質問ですが違和感無く回答が得られています。 　以上、Teamsで利用できるチャットボットの開発です。ChatGPTと同様のAIを利用して、自然な言葉のやり取りができるようになっています。質問内容によってはとても細かく専門的な内容まで回答してくれます。また、新しい取り組みとしてクラウド上でPowerShellをサーバーレスで実行できる環境もうまく動かすことができました。技術的は盛沢山の要素を組み合わせてクラウド完結型のアプリケーションが開発できています。

CI/CDに特化したテックカンファレンス「CI/CD Conference 2023 by CloudNative Days」が、2023年3月20日に開催されました。東京都内のリアル会場とオンラインの双方で参加でき、全部で18のセッションが行われました。GMOインターネットグループではCMスポンサーとして協賛し、自社のインフラCI/CDの実装やその課題と解決に関して情報を提供するセッションをお届けしました。今回はその内容をご紹介します。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームグループ SRE アーカイブ動画：https://event.cloudnativedays.jp/cicd2023/talks/1755 https://speakerdeck.com/ryuichi1208/inhuraci-cdji-sok-de-gai-shan-nodao-nori GMOペパボの古参サービス・カラーミーショップの歴史 GMOインターネットグループのGMOペパボでは複数のサービスを運用しています。例えばカラーミーショップは2005年にサービスを開始しており、GMOペパボの中でも歴史あるサービスのひとつで、このサービスを利用して作成されたECサイトの流通総額は1兆円を超え、トラフィック量の大きなサービスとなっています。 GMOペパボが運用しているサービス一覧 構成は複数のユーザーで1つのリソースを共有するというマルチテナント型。開発体制は、人の流動性が結構激しいものの、アプリケーションエンジニアが数人から30人、SREは6人ぐらいというイメージだと渡部は説明します。 歴史の長いサービスだけあってカラーミーショップではインフラも随時変更されてきました。「オンプレ期」から始まり、OpenStack上のKubernetesでアプリケーションを運用していた時期を経て、現在は「ハイブリッドクラウド期」です。プライベートクラウドとパブリッククラウドに同じ環境を用意して接続し、アプリケーションやサービスを提供するという構成です。 ちなみに、このあたりの情報に関しては、別のイベントでカラーミーショップのエンジニアが解説したスライドがありますので、興味のある方はそちらもご覧ください。 https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji カラーミーショップがたどったインフラの歴史。プライベートクラウド、プライベートクラウド上のKubernetesで稼働していたKubernetes on プライベートクラウド期が現在主流で、ハイブリッドクラウドに移行しているところだといいます。 カラーミーショップのサービス構成 カラーミーショップは3層構造のサービス構成。ロードバランサーはプライベートクラウド、パブリッククラウド上にそれぞれに実装されていて、アプリケーションはVM（仮想マシン）またはKubernetes上に、データベースはAWS上に存在しています。 アプリケーションは80以上のロールで構成されています。基本的にはKubernetesへの移行を進めているそうですが、全てをVMから移行できるわけではなく、現時点ではVMの方がロールの数は多く、しかも一部のロールはコンテナ化しない予定であり、混在環境が継続することになります。 こうしたインフラ周りで使われている技術スタックは以下のようになっています。 プラットフォーム OpenStack、AWS、Kubernetes開発言語Ruby、mruby、GoミドルウェアNginx、MySQL、Redis、memcachedCI/CDGitHub Actions、ArgoCD監視Mackerel、Prometheus、Grafana、ElasticAPM、DataDogIaCPuppet、Ansible、Chef、Terraform ロールのほぼ全てはPuppetで管理されていますが、デプロイパイプラインとしてVMとKubernetesに分かれており、それぞれでCI/CDが異なっています。 VMの場合はOpenStackのレイヤをTerraformで管理。ミドルウェアの管理がPuppetで、ローカルでは各自でVMを用意してPuppetをアプライ。コードが完成したらGitHubにプッシュし、Puppetをアプライしたコンテナに対してServerspecでテストを実施。問題なければインテグレーション、ステージング、プロダクションなど、環境ごとにデプロイして動作確認するというフローになっているとのこと。 Kubernetesの場合は、「kubectlのデプロイは原則禁止で、いわゆるGitOpsのフローを取っている」と渡部。フローとしては、main branchがステージング環境に適用され、release branchがプロダクション環境へ適用されます。 開発ではmanifestの修正をGitHubにプッシュし、Dockerfileのテスト、DockerImageのビルドやプッシュを行い、ArgoCDを用いて実際のクラスターに適用するという流れです。 カラーミーショップが抱える6つの課題 こうしたカラーミーショップの環境には、以下の6つの課題を抱えていると渡部は説明します。 インフラテストへの課題コードとサーバーで差分が発生している問題暗黙知前提の運用問題VMとコンテナ混在問題セキュリティ対応問題使用しているツールが多く、学習に時間がかかる問題 インフラテストへの課題は、端的に「時間がかかりすぎる」というものです。例えばただnginxでパラメーターをひとつ変えるためのプルリクエストを出すだけでも、ローカルのVMにコードを適用するだけで15分、CIでコンテナを起動してコードが適用されるまで20分、合計35分がかかっていました。 デプロイまでのフローには複数の段階があり、些細な修正でも毎回35分程度の時間がかかっていました これだけ時間がかかるのは、CIが毎回プレーンな環境で実行されるという点にありました。プレーンになってしまうので修正以外の部分もやり直しになってしまいますし、「末尾のセミコロンを忘れた」というだけの修正確認でも20分かかってしまうのだそうです。 他にも様々な問題が発生しえます。最終的には「何もしなくても時間の経過とともにシステムは壊れていく」と渡部。 2番目のコードとサーバーの差分については、VMがミュータブルな点、障害対応時のアドホックな対応などが残っている点、ロールが80以上と多数になるため半年近くデプロイされていないものも存在する点などで差分が出てしまうことがあるとのこと。サービス開始当初のコード管理せずに構築されたロールなどもあって、属人化が進んでいるということもあったそうです。 似たような課題が暗黙知前提の運用で、インフラのコードに触れるメンバーがある程度固定化されてしまったため、セットアップする人がおらずに以前のセットアップ手順書が使えなくなってしまったり、メンテナンスがされていなかったり、コード変更作業がSREチームに依頼されるためチーム本来の作業ができないという問題がありました。 3番目のVMとコンテナ混在問題は、積極的なコンテナ化を進めつつもVMが混在する状況で、ミドルウェアの設定変更でVMとコンテナ双方で対応が必要になり、VMに最適化されたnginxなどのミドルウェアの設定も問題が発生することがあります。 セキュリティ対応問題では、パッケージなどの脆弱性をチェックするツールを使っても報告される数が膨大で対応しきれないという点があります。深刻度の高いもの以外は優先度を挙げられないという問題もありました。 学習コストの問題は、使用しているツールの数が多いために発生しています。IaCだけでも複数のツールがあり、運用ツールも多数の言語で実装されていて、現在メインのRubyとGo以外にも複数の言語が存在しています。 そもそも2005年からスタートしているサービスのため、当時の開発者の得意言語で作られたツールがシェルスクリプト、Perl、Pythonなどとバラバラにあり、しかもプロダクションで運用されて使われていることもあるため、メンテナンスのために言語習得が必要になることもありました。 課題をいかに解消するか こうした課題に対しては、まず「課題をどうしたいのか」という定義から始めました。 暗黙知前提の運用のためにインフラに触れるメンバーがスケールせず、「触るのも恐い」という状況で、SREチームがインフラ作業に従事せざるをえないという課題に、「アプリケーションエンジニアも安心して触れる、インフラCI/CDを目指す」ことを目標に改善を目指しました。 解決へのアプローチは以下の通り。 CIの高速化暗黙知の徹底排除テストの拡充開発環境の整備構成ドリフト検出のための仕組みの実装コンテナ on VM監視の見直しデイリーでコンテナイメージをビルドする仕組みの実装権限委譲 インフラテストで1回30分の時間を要していたCIは、GitHub Actionsの設定方法のチューニング、ライブラリやPuppetでのキャッシュや並列化などによって1割程度、2～3分程度は削減。 さらにパイプライン自体の最適化としてキャッシュを有効活用。kernelヘッダーやgccのアップデートなど、変更と関係ない部分をキャッシュしておき、毎日朝に適用済みコンテナイメージをプッシュしておき、当日はそのイメージを利用することで、10～15分の削減に繋がりました。 さらに誰でも簡単に使えるようにすることを目指し、暗黙知前提の運用排除を目指しました。まずはドキュメントの執筆と勉強会、ワークショップの実施もしつつ、CIに関する作業の自動化を進めました。 これはプルリクエストに対して必要なラベル付け、開発環境のセットアップコマンドによる必要なツール類のインストール、テストの拡充など多岐に渡り、テストのたびにGitHubにプッシュする必要がなくなるなど効率化。 コードとサーバーの差分で発生している問題については、定期的に差分検出やコード適用する仕組みを実装。毎朝1回、Terraformのplanをチェックしたり、Puppetの差分確認コマンドも時間を決めて実行し、差分の有無を確認したりしているといいます。 デプロイフローも整理して、GitHub Actionsからしか実行できないように整備しました。変更履歴の管理が容易になって、いつ、誰が変更したかを追跡しやすくなったことがメリットです。 VMとKubernetesの混在問題は、移行期間ということもあって同時に同じアプリケーションが動いていることがあります。これに対してDockerをVMで動かし、1コンテナを1つのVMで動かすことにしました。VMの修正はDockerファイルにコンフィグレーションを含めてビルド。そのイメージをプッシュすることにして、1つの修正でVM、Kubernetes双方に反映される仕組みを実装しました。 セキュリティの課題について、パッケージの脆弱性は最新版で改善されているケースが多いので、Dockerファイルのパッケージバージョンではlatest指定し、ステージングなどで動作確認を毎日行います。latest指定で壊れてしまっても、本番環境には影響が出なくなるわけです。 こうした取り組みによってインフラCI/CDが改善され、エンジニアが触りやすい環境にはなってきました。結果として、SREチームのレビューが必須だったブランチ運用ルールを不要にできたと渡部は説明。 とはいえ、CI/CDの改善による生産性の向上が実現したかは難しい問題だと渡部は指摘します。アプリケーションエンジニアの作業量が増えただけで組織全体では生産性が下がっているのではという懸念もあり、可視化ができていない点が課題なのだとしています。 それでも、SREチーム以外が触りづらかったインフラにおけるCI/CDの改善活動を続けて、状況は良くなってきました。現在も試行錯誤中ですが、GMOペパボにおける「コンテナとVMの混在環境」というのは、一般的に起こりえる状況なので、解決するための知見を今後もアウトプットしていきたいと渡部は話していました。