ソフトウェアエンジニアリング 学習ログ

Docker入門 Architecture SQL Haskell Vim セキュリティ

ソフトウェアエンジニアリング 学習ログ とは

このサイトはとあるソフトウェアエンジニア/SREがIT業界を生き残るために学び続けた学習ログです。

私は デスクトップエンジニアからWEB系(バックエンド/フロントエンド)を経由しSRE として活動してきました。 その際にはコーディング、コンテナ、データベース、IaC、オブザーバビリティといったエンジニアとして生き残るために学び続けた知識をアウトプットすることで吸収してきました。

アウトプットの場としてきた以上読みずらい/荒い情報もあるかと存じますが、このサイトを訪れた誰かのためになれば幸いです。 (本記事の後半は私のキャリアについて記載されていますが、これは私自身の名刺としての役割を期待するものです。ご承知おきくださいませ。)

目次

👦 対象者

  • 荒い情報でも問題ない人
  • プログラミング入門本を読み終わった学生
  • エンジニア歴1年目~10年目(目安:新卒~マネージャー未満)
  • SRE

📗 目次

ソフトウェアエンジニアリング

🦫 筆者

みねぎしれい(27)

エンジニア(7年)/マーケター(1年)です。
・エンジニア : ネイティブアプリケーション/バックエンド/フロントエンド/インフラ/SRE
・マーケター : toBマーケティング(LP制作からう共催ウェビナー準備など)/採用広報チームリードを担当

  • 企画段階
    • ペルソナ策定(マーケ)
    • ユーザーインタビュー(マーケ)
    • LP制作(マーケ)
    • プロトタイプ構築(エンジニア)
  • プロダクト初期
    • ディストリビューション戦略策定(マーケ)
    • IaC/CICD(SRE)
    • コーディング(エンジニア)
  • プロダクト運営
    • サービスレベル(SRE)
    • 行動監視(マーケ)

🏢 職歴

趣味

  • ☗️ 将棋
    • 好きな戦法 : 居飛車穴熊
    • 序盤は指回しや方針決めに性格が出るのが面白い。
    • 終盤は一手の重みがより重要になる。スリル感がたまらない。
    • 「大事な場面で勝負強くなりたい」という方におすすめ
  • 🔫 シューティングゲーム
    • 好きなタイトル : VALORANT

その他

  • 色
    • インディアンレッド #CD5C5C
    • Firebrick #B22222

実践的行動理解 / マーケティング

「実践的行動理解 / マーケティング」サイトは、心理学を幅広く学び、実生活や仕事に応用できる知識を体系的に整理したサイトです。信頼性が高い論文を集め内容を解釈し、応用可能な知識として配布します。

以下のように、行動理解を促進させる記事を中心に取り扱います。(これは、実践的かつニッチな行動理解についての論文が圧倒的に多かったためです。)

また、 ブルズアイフレームワークによるトランザクションの選択と集中 など マーケティングに集中した記事も取り扱います。

このように、実践的な行動の理解を促進する / マーケティングを有利に進めるという類の記事が多いです。

注意:研究の信頼性について

可能な限りデータ/信頼性の高い情報元から記事を作成していますが、そもそも心理学の研究に対する疑念を表す研究結果も存在しております。 記事は100%信頼せず、成功確率を上げるための一要因として考えてください。

page:https://minegishirei.hatenablog.com/entry/2023/01/27/193827

MLOpsパイプライン

データはビジネス要件によって変化するため、それを前提している機械学習モデルは賞味期限があります。 (=データドリフト) 一度作ったモデルは永続ではないということです。

これらの理由から、MLOpsでは「機械学習モデルを構築すること」が目標ではなく、 入力値(データ,コード,パラメータ)を受け入れ、高品質のモデルを作成しアプリケーションと統合できる自動化されたMLパイプラインを作ることです。

MLOpsパイプライン全体像

以下がMLOpsパイプラインの全体像です。 プロジェクトによってレイヤーが追加されたり、削除されたりします。

一般的には、データの準備、訓練、評価、登録、デプロイで構成されます。

MLOpsパイプラインのトリガー

MLOpsパイプラインのトリガーにはいくつか候補があります。

  • 開発・データ変更起点
    • Code Push Trigger : ソースコードリポジトリへpushされたときに駆動するパイプライン。
    • Data Arrival Trigger : 日次・週次で新規データが入ってきた際の前処理・特徴量ストアとして機能します。
    • Feature Store Update Trigger : 特徴量の変更に伴うモデルの再学習
  • 定期実行・時間起点
    • Cron Trigger : 定期的なモデルの再学習
  • 運用・パフォーマンス監視起点
    • Data Drift Trigger : 本番環境に入力されるデータの分布が、学習時のデータ分布から大きく乖離した時に駆動させる。
    • Performance Degradation Trigger : 本番環境でのモデル予測精度指標

初期フェーズでは開発・データ変更起点、定期実行・時間起点を使用し、 成熟フェーズではモニタリングを応用した監視をするのがおすすめです。

ただし、これらは「リアルタイムパイプライン」には使用できません。

MLOpsパイプラインとデータ

MLOpsではデータがないと始まりません。 パイプラインはどうにかして、複数のリソースの履歴データorオンラインデータにアクセスする必要があります。 加えて、入手した生データはそのままの形では使うことができません。 ほぼ必ず、特徴量エンジニアリングが必要になります。

データはアーカイブデータシステム/データウェアハウスに保管される場合があります。 これは、法規制や将来の分析・監査のために長期間保持しておく必要があるデータを、効率的かつ安全に管理するためのシステム基盤です。

構造化オブジェクト形式(json)が役に立ちます。 これは、項目（キー）が増減しやすいため、厳格な表形式（RDB）よりも、柔軟な構造化オブジェクト（JSON形式など）の方がそのまま突っ込んで管理しやすいという特徴があります。

MLOpsパイプラインのバックアップ

MLOpsパイプラインのデプロイの結果、アプリの品質が落ちた場合にはそのモデルを取り下げて、元のモデルに戻す必要があります。 この時に、元のモデルに必要な項目は何があるでしょうか?DevOpsではソースコードだけでよかったですが、MLOpsではそうではありません。

  • バージョン
  • ソースコード/モデル
  • データの発信元の情報(特徴量の情報)
  • 訓練パラメーター

MLOpsではこれらの情報をセットとしてバックアップを取る/データリネージを行う必要があります。

まず、パイプライン実行時には各モデルには一位のIDが割り振られています。 そして、データドリフトが発生しても再現性が得られるようにデータもスナップショットを取得して、そのIDとモデルの紐付けも行います。

すべてのデータを毎回物理コピーするとストレージを圧迫するため、実運用では Delta Lake、Apache Iceberg、あるいはオブジェクトストレージ（S3/GCS）でのタイムトラベル機能（バージョン管理） や、軽量なポインター（ハッシュ値によるデータセットの参照管理）を活用することが多いです。

MLOpsにおけるデータリネージの担保が最大の難所ですが、以下の対抗策があります。

  • トランザクションログ（ACID特性）をベースに特定のタイムスタンプやバージョン時点のデータを取得できるようにする。
  • 特徴量ストアの導入しバージョン管理。 推論時と学習時で同じ特徴量を再現させる

特徴量エンジニアリング

特徴量エンジニアリングのプロセスはSREそこまで関与しませんが、注意を払うべき点があります。

モデルの開発者(データサイエンティスト)は特徴量を視覚的に探索していき、予測したい情報と関連があるものを選択していきます。 同時に、特徴量から作成される派生特徴量も生成し、理論の確認を行います。 無関係な特徴量を削ることも仕事の一つです。

そしてここからがSREの仕事ですが、 手元の端末でどのように特徴量エンジニアリングをおこなったのかを忘れずに、その変換過程を明記させておく必要があります。 本番の実装ではより大規模なデータで上記の特徴量エンジニアリングをおこあうことを留意してください。

  • 対数変換 : 金額やアクセス数など、偏りの激しい分布を対数で圧縮し、モデルが扱いやすい正規分布に近づける。
  • ピン化 : 複数の値を一つのカテゴリにグループ化する。
  • 外れ値の検出 : 各特徴量の値が指定した範囲から外れるものを削除する
  • ワンホットエンコーディング : バイナリ(0/1)に変換する。
  • 時間データからの抽出 : 日付から曜日と時間と休日などを抽出する。
  • データのラベル付 : 機械学習モデルに予測されるターゲット属性を示すために、データにタグを追加します。
    • たとえば、株価の売り買いを調べるためには、過去の月の行動を入力値とし、その次も株を保有していたかどうかを調べます。

特徴量ストア

MLプロジェクトの難しい点の一つに、プロジェクトの構成が挙げられます。

  • データサイエンティストとアプリケーションエンジニアは別で動く
  • オンラインでの作業とオフラインの作業でデータが重複し、管理が難しくなる。
  • そもそも特徴量が存在する本番開発環境にアクセスできない。

これらを解決する手段として、特徴量ストアがあります。 特徴量ストアは本番環境のデータベースとは別に存在し、プロジェクトで使用する可能性のある全ての特徴量を保管するデータストアです。

モデルの開発とパイプラインファースト

MLOpsの究極状態は、全てのトレーニングをローカル端末ではなくパイプライン上で完結できる状態です。 ノートブックでの検証はあくまで検証の状態であり、本格的な訓練とその結果はパイプライン上で行うことが理想です。 そのため、Devops/SREで推奨される、開発の早い段階でパイプラインを作る「パイプラインファースト」が推奨されます。

Jupyter Notebookの限界

一つのJupyter Notebookで全ての管理するやり方もありますが、バージョン管理の難しさ、 コードのリファクタリングの必須さ、データの再現性の低さの観点で、推奨されません。

MLパイプラインは要件があります。

  • 複数の学習を同時並行でできるようにする。
  • パイプラインの各フェーズで、入力と出力がビジュアライゼーションされている
  • 以下をまとめて保管する「バックアップ機能」
    • バージョン
    • ソースコード/モデル
    • データの発信元の情報(特徴量の情報)
    • 訓練パラメーター

データの品質テスト

モデルのテストフェーズにうつる前に、訓練データに問題がないかを事前に確かめる必要があります。

特に、データセットの、特定の値の平均と標準偏差が基準内に収まることがバイアス排除のために必要です。 以下のカラムで平均/標準偏差に問題ないか確認が必要です。

  • 年齢
  • 収入
  • 性別

モデルの品質テスト

データ品質に問題ないことが確認できたら モデルの品質を確認します。

  • モデルの正答率が低下してないか
  • 性別や年齢の特定の範囲で正答率が低下していないか
  • 特徴量で不要なものがないか
  • ランダムな入力で誤作動が起きないか。

モデルとアプリケーションの統合

モデルとアプリケーションの統合には、大きく分けて3通りのやり方がある。

  • API :
    • 用途 : レコメンド、不正検知、チャットボットなど。
    • 構成 : FastAPI + ONNX Runtime の構成
    • REST/GraphQLなどの規格が使われる。
  • バッチ推論 :
    • 用途 : レポート生成、夜間バッチでのスコアリングなど。
    • 構成 : SnowflakeでPythonの独自モデルが動かせる。AWS Batchなどでも可能。

page:https://minegishirei.hatenablog.com/entry/2026/10/12/020607

Dear My Frends.: 個人開発宣伝ラボ - 個人開発者が間違った施策で時間を溶かさないための、心理学と実務知見のナレッジ共有コミュニティ