データサイエンスによる製品ユーザ経験の改善

問題

Qoveryは、連続配備プラットホームです.ユーザーはすべての種類のアプリを展開し、選択した任意の言語とフレームワークで記述されます.自由ユーザーはQoveryコアチームのコストが付属している-広い範囲Qoveryカバーする必要があります、それは困難に配置プロセスを安定し、誰にとっても簡単になります.それは簡単に1つの言語やフレームワークに焦点を当てたサービスを作成する-それらのすべてをサポートするより多くの要因を考慮する必要があります.
我々は直面している課題は、ユーザーが任意の言語とフレームワークを選択できるように信頼性の高い、できるだけ簡単に展開を行うことです.我々は自動化し、優先順位を優先し、最初に最も緊急の問題を修正することができる最も一般的に発生する問題を見つけるのプロセスを簡素化する必要があります.
すべてのケースについて予見して準備することはできません-スコープはあまりに広いです.アプリケーションの任意の種類のすべての展開を展開し、スムーズに実行し、最も一般的な問題を把握するために、我々はデータ駆動アプローチを使用して、私たちのユーザーが自分のアプリを展開しながら直面している問題を決定するプロセスを簡素化するためにいくつかの簡単なMLツールを使用してください.
データを収集し、測定を行い、データ駆動された行動をとる科学的アプローチを受け入れることは、我々のユーザーアプリケーションを構築して、展開する際に最も一般的な問題を見つけて、修正する唯一の方法です.
エラー報告

エラー報告

Qoveryに配備すると、配備エンジンがアプリケーションのビルドと展開を実行します.展開パイプラインで遭遇したどんなエラーもQoveryに報告されます.
レポートのエラーの例を以下に示します.

{"scope": "ENVIRONMENT", "state": "DEPLOYMENT_ERROR", "message": "\n-------------------------------------------------------------------------------\n\n MESSAGE FOR QOVERY TEAM:\n * Execution ID: 0548486d-0605-4b64-8049-24954ceec8e0-13-1625428767\n * Scope: Build platform 'beta-build' with id 'ze9e19029'\n * Rollback message: \n\n-------------------------------------------------------------------------------\n\n \u274c \u274c \u274c MESSAGE FOR THE USER \u274c \u274c \u274c\n\n \u2709\ufe0f Error message: Qovery can't build your container image beta-build (ze9e19029) with one of the following builders: heroku/buildpacks:20. Please do provide a valid Dockerfile to build your application or contact the support.\n \ud83d\udcac Need help: Look at the hint message first. If you need more assistance, you can reach the support team on Discord (https://discord.qovery.com) or on the Qovery console (https://console.qovery.com) with the integrated chat.\n \u2139\ufe0f Hint: None builders supports Your application can't be built without providing a Dockerfile\n "}

or

{"scope": "ENVIRONMENT", "state": "DEPLOYMENT_ERROR", "message": "\n-------------------------------------------------------------------------------\n\n MESSAGE FOR QOVERY TEAM:\n * Execution ID: d5ab51f0-94d3-4671-8dc6-77fc228f2e35-6-1627037439\n * Scope: Build platform 'beta-build' with id 'ze9e19029'\n * Rollback message: \n\n-------------------------------------------------------------------------------\n\n \u274c \u274c \u274c MESSAGE FOR THE USER \u274c \u274c \u274c\n\n \u2709\ufe0f Error message: error while building container image beta-build (ze9e19029). Error: SimpleError { kind: Command(ExitStatus(ExitStatus(256))), message: Some(\"error while executing an internal command\") }\n \ud83d\udcac Need help: Look at the hint message first. If you need more assistance, you can reach the support team on Discord (https://discord.qovery.com) or on the Qovery console (https://console.qovery.com) with the integrated chat.\n \u2139\ufe0f Hint: It looks like there is something wrong in your Dockerfile. Try run locally using `qovery run` or build with `docker build --no-cache`\n "}

我々はこの種の誤りを何百も集めている.このデータに基づいて、ユーザーが遭遇する最も一般的なエラーは何かを見つけ出す.

パイプライン

プロセスの最初のステップはETLパイプラインに似ています.まず、データストアからデータを抽出します.そして、それを我々の分析ユースケースで使用できるように変換します.最後に、私たちは別の場所に読み込まれ、分析の入力として使用されるデータの新しいセットを思い付く.
下の写真は、プロセスのすべてのステップの視覚的な表現です.私たちは記事の次のセクションでより密接に各部分を通過します.

エキス

我々のパイプラインの最初のステップは、データストアからデータをエクスポートすることです.我々が持っているデータ量とデータベースが他のプラットホーム機能によって生産で使われるという事実を考えると、我々はデータの毎日のダンプ/バックアップをとって、以下のパイプライン・ステップで入力としてそれを使用します.

変換

しかし、我々が格納するデータは、我々がしたいことのためによく構成されません.最初の目的でエラーメッセージを処理するように設計されていませんでした.したがって、それが我々のゴールに役立つ前に、我々はデータを前処理する必要があります.
例として、Qoveryプラットフォームのパフォーマンスを向上させるために、バッチ展開イベントを受け取ります.これは、複数のイベントを1つの単位に格納します.したがって、入力データを準備するために、我々が取る最初のステップは展開イベントの1つのフラットリストにそれらのメッセージを平らにすることです.
我々の入力(生のエラーログのフラットリスト)がある後、我々は別のステップを開始-データクリーニング.シャープで正しい答えを提供するために、私たちのデータを、パイプラインでさらに使用するアルゴリズムのプロセスとセグメントによりアクセスできるようにする必要があります.
これらのステップはNLPでかなり標準であり、以下のようなものを含みます:

メッセージを下げること
句読点

を取り除いている

空白242479182を取り除いている

空のメッセージ

を除去する

このコードは非常に簡単です-データマッピング関数を入力データで実行するだけです.

 output = list(map(no_uppercase, data))
 output = list(map(no_numbers, output))
 output = list(map(no_punctuation, output))
 output = list(map(no_stopwords, output))
 output = list(map(no_whitespace, output))
 output = list(map(no_qovery_specifics, output))
 output = list(map(no_unicode, output))
 output = filter(non_empty, output)

マッピング関数の例

def no_numbers(log): return {
 "scope": log["scope"],
 "state": log["state"],
 "message": re.sub(r'\d+', '', log["message"])
}

目標は、MLアルゴリズムの効率的にログ構造化することです.

負荷

Transform Stepの終わりには、比較的小さなデータのセットで終わります.今のところ、私たちはJSONファイルに保存し、単純なNLPスクリプトの入力として使用します.
Python
Pythonは、言語がどれだけシンプルであるか、そしてNLP/MLスペースに存在するライブラリをテストしたバトル数に優れています.qoveryでPythonをあまり使わないのに、このケースで選ぶのは簡単な選択でした.
我々はあまり自分自身を実装する必要はなかった.それぞれのアルゴリズムは既に実装されており、人気のあるPythonライブラリの多くによってテストされています.データのクリーニング、データのクラスタリング、データのクラスタリングなど、後の手順を経てデータのクリーニングを開始します.
我々がしなければならなかったすべては、入力データを準備して、ライブラリを構成して、最高の結果を成し遂げるためにパラメータで遊びます-パイソンML生態系が広大で、あなたが必要とするすべてを提供するので、あなたは多くの自身を実行する必要はありません.
使用するライブラリ

NTLK

gensim - doc 2 vec

のSkLearn

ベクトル化データ

データが変換された後、我々がしたいことは、テキストデータ(エラーメッセージ)をベクトル化することです.なぜ我々はデータをベクトル化したいですか?
NLPでは、ベクトル化は単語や文章を実際の数のベクトルに写像するために使用されます.
また、クラスタリングのためにベクトル化されたデータを使用することができます、これは我々が達成したいものです-グループのエラーログは、我々はQoveryで展開の成功率を改善するために対処することができます配置問題に共通の発生パターンがあるかどうかを見ることができます.
ベクトル化データに使用されるメソッドは、gensimからのdoc 2 vecです.ライブラリを使用すると、入力データを使用して1つの関数を実行し、パラメータを調整するのと同じくらい簡単です.

def transformToVectors(data):
 return Doc2Vec(data, vector_size=80, window=2, min_count=1, epochs=1000)

‍

クラスタリング

このステップでは、ベクトル(私たちのドキュメントの数値表現-この場合はエラーログ)を取り、それらの類似性に基づいてグループ化します.

雑音を用いたアプリケーションの密度ベース空間クラスタリング

グループエラーに使用されたメソッドはdbscanです.この方法の背後にある原理はかなり単純です-それは、距離(通常ユークリッド距離)とクラスタを作成するのに必要な最小限のポイントに基づいて互いに近接しているポイントをグループ化します.彼らが低密度の地域に位置するならば、それは外れとして点をマークします.
実装は、データのベクトル化と同様に、ライブラリにデータを入力し、パラメータを調整するだけです.

def dbscan(vecs):
  return DBSCAN(eps=.2, min_samples=5, metric='cosine').fit_predict(docvecs.index_to_key)

エラーの識別

dbscanの結果は多数の異なるエラーグループを提供しました.各グループの誤りは互いに関連している.この(マニュアル)ステップでは、私はすべてのグループを通過し、最大のものから始め、グループの問題の根本的な原因に掘り下げた.
結果は非常に正確でした-通常、1つのグループの誤りの大部分は1つまたは2つの根本原因に起因しました.原因を見つけるのは必ずしも簡単ではありませんでした-この部分は、少しの掘削と理解を必要としました.
不明確な原因があるエラーについては、潜在的な修正を実施し、後に新しい展開の結果を測定することによって、私たちの推測を検証する仮説と計画を思いつきました.

洞察

簡単なMLパイプラインの出力解析から得られた結果と洞察

~エラーの23 %はBuildPackを使用してビルドプロセス中に発生しました.

~ 17 % -ビルド

でビルドビルダーが使用するものを確認できませんでした

～16.5 %- Kubernetes活性問題の障害-主にユーザアプリケーションのために、起動設定フェーズ

の間にアプリケーションを誤って設定するか、クラッシュさせる

~ 6 %-別のビルドパックの問題- 1つ以上のプロセスの実行によるアプリケーションのエラーとデフォルトのビルドパックの設定は、アプリ

を起動することができない設定

~ 5 %-ユーザーが242479182によって提供されるDockerイメージを構築している間、エラーを構築してください

と2つのサブ2 %エラーは、クラウドプロバイダの制限による展開の失敗、Gitリポジトリの問題、APIやQoveryエンジン

のマイナーバグのようです.
それらの洞察力と数字を考え出すことは、展開を分析するプロセスを自動化することなく、可能ではありません.展開の数と我々のユーザーが展開するアプリケーションの種類が異なると、“手動”を行う方法はありません.
データ駆動型アプローチを受け入れることで、データベースに既に存在している情報を利用して、最も一般的なエラーは何かを理解し、問題解決の順序を優先することができました.また、多くのより頻繁に発生する問題を特定することができました.

概要

PythonとシンプルなNLPでこのような短い時間で達成できることはとても印象的です.データサイエンスの知識がほとんどない人は、大量のデータを処理し、サービスを改善するために使用できる貴重な洞察を開発するために既存のライブラリを使用することができます.
以下の手順は、エラー報告データを分析して、改善された場所を確認し、新しい問題が発生していることを繰り返します.今、私たちが学んだ洞察力を利用し、防弾を構築する時です.