nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

VertexAIの疑問点

※WIP

全体

  • 対応リージョンの制限はあるか(tkyで利用できるか)
  • リリースバージョンはGAか
    • Vertex AI Workbenchなど含めて

データ基盤(収集, 蓄積, 加工)

  • データセットの利用シーン、利用方法は何か。BQ直接利用との違い(使い分け)は何か。
  • データの実態はどこにある?同じデータセットを利用しても、元のデータ(BQなど)が変わっていると、結果が変わる?

ラベリング

データ分析環境

  • ノートブックを作成するとエンドポイントが起動して、ブラウザでhttpアクセスできるのか
  • メンバー間のノートブックの環境を合わせるにはどうすれば良いか。pip?コンテナ?パイプライン化までのフローを踏まえてどうするべきか。
  • 従来のノートブックとWorkbenchの違いは何か
  • マネージドとユーザ管理の違いは何か
  • カスタムDockerイメージを使う場合の制約はあるか。特定ポートでJupyterを起動するなど。
  • 実験管理はどうやるか。Experimentsは何ができるか。Metadataとの違いは何か。
    • Metadataを実験管理ツールとして利用することはできるか
  • ノートブックへのアクセス権はどう制御すれば良いか。
  • ノートブックからのアクセス権はどう制御すれば良いか。

実験管理

  • 実験管理できるか。実験管理できる項目は何か。

学習基盤

  • データ分析の一環としてDSがジョブを投げ込むことができるか(ノートブックとの連動)

モデルレジストリ

  • モデル管理として何の項目が管理できるか。メタデータ管理との使い分けは何か。

サービング

MLパイプライン

  • 登場人物の全量
  • ノートブックと実行環境をどう揃えるか
  • AutoMLとの連携はどうやるか。スクラッチ実装と比較して(併用する場合)、手順のどこがどう変わってくるか。
    • サービスのくくりが同じだから(AutoMLもVertexAI)、連携できるはず?
  • バッチ実行もエンドポイントを起動する必要があるか。推論処理を実行したいときのパターンは何か。(オンライン含めて)
  • ノートブックからパイプラインへの変換の過程、登場人物の全量。CIで完結するか、自前でファイルを書く必要があるか。
    • ファクトリ関数を使うもの?CIで実行する?
  • パイプラインの起動方法。SDKのみ?
  • パイプライン起動のトリガー、スケジューラ
    • Kubeflow Pipelines SDKのスケジューリング機能 やCloud Composer、Cloud Scheduler?それぞれの使い方
  • コンポーネント間の中間生成物はどこに保存される?
  • kfpはv2?
  • コンポーネントそれぞれにスペックを割り当てることができるか。GPUの指定など。スケールアウトすることができるか(台数指定も)。
  • エラー検知、切り分け、リランはどうやるか
    • 途中からの実行はどうすれば良いか。エラーのジョブ実行結果は消えるのか。
  • 実行結果のキャッシュとは何か。リランした時に処理がスキップされる?キャッシュを使う条件は?
  • Kubeflow Pipelines SDKとTensorFlow Extended(TFX)の二通りがある?使い分けは?
    • テラバイト単位の構造化データまたはテキストデータを処理するTensorflowならTFX?
  • 引数はどこで渡してどう流れていく?
  • Metricsはどう指定すれば何ができる?コンテナでは無理?
  • デプロイするときは(エンドポイントを作成したい時は)、デプロイのコンテナ使ってさらにイメージを指定する?
  • 実行はコンテナのみ?
  • コンポーネントごとにGPU有無などのスペックの指定ができる?
  • 後から確認できる項目は何か。コンポーネントを選択すると、パラメータや処理時間や実行ログ?
  • AutoMLと併用した場合に、metaデータへの連携はどうなる?(前処理は自前実装、学習はAutoMLなど)
  • リソース制限はあるか。無限にスケールするのか。
  • 分析環境・学習パイプライン・推論パイプラインはPJを分けるべきか
    • 特に、BQへ書き戻す場合の権限制御
  • パイプラインの動作確認はどの環境で実施するべきか
  • DataflowやDataprocとの併用はどうすれば良いか
  • OpFunc関数とは何か
  • 認証情報はどう取得するべきか(GCP
  • モデルのサイズ制限10GB(N1)?
  • パイプラインの実行状況確認、停止、削除はできるか
  • Trainingと自前実装の違いは何か。
  • Predictionと自前実装の違いは何か。
  • Metadataへ、任意のパラメータやmarkdownを連携・可視化することはできるか
  • 依存関係の制御は、データのIn/Outか。マニュアルでの制御も可能か。
  • GCSを使わずにBQに書き戻す場合もメタデータ管理は可能か

メタデータ管理

  • In/Outデータ、コードバージョン、ハイパーパラメータ、精度、学習曲線、混同行列は管理できるか
  • ノートブックからも利用できるか

CD(MLパイプライン, サービング)

  • ノートブックの作成から、パイプライン実行までを自動化した場合の流れは何か。(手動の部分は手動)
    • コミット、テスト、パイプラインのデプロイ=実行?、通知、承認

特徴量ストア

  • 特徴量ストアは何が嬉しいのか。どういうときに利用するべきか。
  • Analytics hub経由でデータセットをコントロール下に置きながらベンダーに依頼することはできるか。

CI

  • CIはどのサービスと連動させるのが良いか。

モニタリング(精度含む)

  • モニタリングは具体的に何が監視できるか。
    • 分布の比較をしてくれる?どことどこの比較?
    • VertexAIのEndpointを利用する場合のみ?

ECS設定チェックリスト

メモ

ネットワーク

  • VPCエンドポイントが色々必要
    • S3, CloudWatchLogs, ECR, etc
    • S3はインターフェース型もゲートウェイ型もどちらも必要

デプロイ

  • CodeDeployと連動させて、ローリング or Blue/Green
    • Blue/Greenがおすすめ
  • 環境ごとにリポジトリ・デプロイのルールを変える(リポジトリポリシー、CodeDeploy)
    • 開発:手動プッシュを許可
    • ステージング:CI/CDからのプッシュのみ許可
    • 本番: ステージングデプロイ済モデルのみデプロイ可能
  • 環境ごとに固有のタグ識別文字を付与し、タグごとのライフサイクルポリシーを指定する
  • タグは、環境識別子+コミットIDがおすすめ
  • イメージの上書き禁止設定をする。(IMMUTABLE設定)
  • デプロイ前に承認アクションを設定する
  • パスワードとかはSecret Managerでsecure stringとして管理する

監視

  • SNSからChatbotに連携してSlack通知
  • FireLensでログ運用する
    • -> CloudWatch Logsよりおすすめ
    • サイドカーパターンで配置する
  • CloudWatch Container Insightsを活用する

セキュリティ

  • ECS/FargateはPCI DSS準拠
  • 金融サービスに関するWell-Architectedフレームワークレンズを参考にする
  • ECRによる脆弱性スキャン+Trivyによる脆弱性スキャン
  • dockleでベストプラクティスチェック
  • -> CIの中でTrivy+dockle
  • WAFをALBと連携させる
  • コンテナレジストリの暗号化(作成時)

性能

  • オートスケールはステップスケーリング or ターゲット追跡スケーリング
    • ターゲット追跡スケーリングがおすすめ

踏み台

  • SSMのセッションマネージャ
    • SSMエージェントを仕込んでおく
  • または、Amazon ECS Exec

運用

  • ECSはAWSの完全なサポートを受けられる(オーケストレータ部分含めて)
  • FargateはEC2よりも割高なので注意
  • FargateはOSのセキュリティパッチ適用や各種ライブラリのアップデート作業が不要になる(運用工数削減)
  • 開発・ステージング環境はLambdaで稼働時間帯を調整する

参考

MLOps導入に向けたヒアリングチェックリスト

はじめに

  • MLOpsの導入・改善を頼まれたときに、初手でヒアリングすることの簡単なチェックリストです

ヒアリング事項

前提条件

(現時点/これから)

スコープ

(現時点/これから)
基本的にはGoogleのこれの通りのステップで導入を進めて行けば良いと思っています。

レベル0: 手動プロセス

  • ☑︎データ基盤(収集, 蓄積, 加工)
  • ☑︎ラベリング
  • ☑︎データ分析環境
  • ☑︎実験管理
  • ☑︎学習基盤
  • ☑︎モデルレジストリ
  • ☑︎サービング

レベル1: ML パイプラインの自動化

  • ☑︎MLパイプライン
  • ☑︎メタデータ管理
  • ☑︎CD(MLパイプライン, サービング)
  • ☑︎特徴量ストア

レベル2: CI / CD パイプラインの自動化

  • ☑︎CI
  • ☑︎モニタリング(精度含む)

その他

  • ☑︎背景・課題
  • ☑︎作業内容と役割分担
  • ☑︎想定アウトプット
  • ☑︎スケジュール
  • ☑︎体制

参考

機械学習シートシート

ロードマップ

f:id:noko_htn:20211009182623p:plain

Roadmap: How to Learn Machine Learning in 6 Months

チートシート

全般

回帰、推薦(教師あり-予測対象が連続)

分類(識別)(教師あり-予測対象が離散)

PCA(教師なし-予測対象が連続)

クラスタリング(教師なし-予測対象が離散)

AWSのセキュリティ設定チェックリスト

メモ

アイデンティティとアクセス管理

  • IAMユーザにMFA設定をする
  • IAMユーザにIPアドレス利用制限をする
  • IAMユーザのキーペアをハードコーディングせずIAMロールやCognitoで代替する
  • IAMユーザのキーペアを利用するなら環境変数に設定する
  • IAMのポリシーに職務機能のAWS管理ポリシーを利用する(閲覧専用ユーザなど)
  • CognitoのMFA設定をする
  • S3バケットポリシーで、特定のVPCエンドポイントからの接続以外は全てアクセス拒否する

発見的統制(ログと監視)

  • Inspectorで、セキュリティ評価を実施する(脆弱性も検知できる。エージェントをインストールしておく)
  • System Managerを組み合わせて、Inspectorの検知結果の対策の適用を自動化する
  • Athenaによるログ分析用のクエリを用意しておく
  • VPC Flow LogsをCloudWatch LogsまたはS3に格納する

インフラストラクチャ保護

  • WAFでカスタムヘッダを利用したアクセス制限をする
  • AWS Shieldを有償プランにする(デフォルト)
  • Route53でヘルスチェックをする
  • Route53で特定地域限定設定をする
  • S3バケットにOAIのみが読み取り可能設定をする(CloudFrontにOAIという特別なユーザを設定する)
  • S3バケットに、CloudFrontからのアクセスのみ許可するようにする
  • CloudFrontで署名付きURLまたはCookieを発行して、アクセス制限をする
  • NLBで、IPを固定する要件がある場合に対応する
  • API Gatewayで、低レイテンシが要件である場合はREST APIではなくHTTP APIを利用する。ただし、Cognitoユーザプールを利用できないのでJWTを利用する。

データ保護

  • KMSでは1年ごとにキーローテーションがされるが、必要に応じて手動でもキーローテーションをする
  • KMSを利用して、SDKでKMSのAPIを呼び出し、暗号化する(CMKで暗号化できるのは4KBまで、リージョン間でそれぞれ作成する必要がある)
  • RDSの暗号化も、リージョンを跨ぐ場合は異なるKMSのCMKを指定する必要がある
  • RDSでSSLを用いて暗号化する場合は、--ssl-caオプションで証明書を指定する(証明書の更新は手順をテストしておく)
  • RDSの認証にIAM認証を使用する
  • S3 Glacierでボールトに保存されたデータをロックして修正できないようにする(S3でも可能)
  • S3のバケットごとにキーを設定して暗号化する
  • Secrets Managerにパスワードを格納する。アプリケーションからキーを指定し、Value(パスワード)を取得する
  • Secrets Managerの自動更新設定をする

インシデント対応

  • AWS Configで設定履歴を保存する+各設定がルールに準拠しているかチェックする
    • EBS暗号化
    • CloudTrail有効化
    • S3のパブリックアクセス不可
    • SGで22がパブリック公開になっていないか
    • 指定したタグがリソースに設定されているか
    • 指定したAMIが使用されているか
  • System Managerの
    • Session Managerでサーバにssh+操作ログの保存+Run Asでユーザ指定
    • Run Commandで複数サーバに一括コマンド実行
    • Inventoryで稼働するソフトウェアの一覧を表示
    • Patch Managerでパッチの適用状況の確認および自動適用
    • Explorerでパッチの適用状況の確認
  • Trusted Advisorでアカウントの状況を5つの観点をチェックする(ビジネス以上)
  • GuardDutyでAWSリソースの脅威(不正やセキュリティイベント)を検出する(EC2内やLambda関数は不可)
  • Security HubでGuardDutyなどのセキュリティサービスの検知内容を集約して確認する
  • DetectiveでGuardDutyなどの検知イベントを時系列で分析する

参考