Google Cloud Platformエンタープライズ設計ガイド　vol.4

前回からの続きです。

６章　機械学習サービス

機械学習の定義：大量のデータをコンピュータに学習させて新しい未知のデータを与えたときにそれを正しく判断するルールをコンピュータ自身に獲得させること。
そのためには学習段階で解答の導出につながる良いデータが必要。統計的な性質などの深い理解と洞察が求められるためどうしても試行錯誤的な長期的取り組みになる。

【２つの機械学習サービス】
①クラウド事業者が保有しているデータで作った学習済みのモデルを利用者が活用できる
②利用者自身が保有しているデータで独自の機械学習モデルを作成するのを助ける

①のサービスについてGoogleは検索・メール・動画などからのサービスを通して得た大量のデータを利活用して知的に処理する機械学習モデルを提供している。このモデルは利用者のプログラムから呼び出して利用できるAPIとして提供されている。
（例：テキストデータを異なる言語に翻訳するCloud Translation API）

ただ、あくまでデータ分析を行った結果なので世の中に多く流通しているデータから得られる結果しか反映できない。こうした条件ではなく利用したい場合は利用者が独自のデータで独自の機械学習を行ってモデルを作成する必要がある。
（例：独自の機械学習モデルを作成する環境やツールを提供するマネージドサービスであるCloud Machine Learning Engine）

これらは完成済みのAPIやフルマネージドサービスとして整備されているので利用者はインフラを考慮することなくサービス利用に注力できる。
【学習済みAPI】
学習済みAPIはいずれもREST APIとして用意されており各APIのURIに対して画像やテキストデータを入力しリクエストを送ることで学習済み機械学習モデルによって処理された結果がJSON形式のデータとして返される。この機能は（C#,GO,Java,Node.js,PHP,Python,Ruby)を使うことでAPIリクエスト/レスポンス処理を任せて簡単に利用することができる。

大容量のデータはCloud Storageに格納したファイルやHTTP(S)でアクセス可能なファイルURLを指定してAPIに渡すことも可能。

【Cloud Natural Language API】
テキストデータの構造と意味を解析する。自然言語処理の基礎となる構文解析のようなベーシックな機能から感情分析やテキスト分類といった直接応用的な機能もサポート。
（例：エンティティ分析
テキストからエンティティ（普通名詞または固有名詞）を抽出
入力として与えたテキストに対して以下のパラメータを返す
-name：エンティティ名称
-type：エンティティの種類（人物、場所など）
-metadata：知識リポジトリのソース情報（WikiのURLなど）
-salience：そのエンティティのテキスト全体に対する重要度
-mentions：そのエンティティが言及されているテキスト内の位置）

【Cloud Translation API】
テキスト翻訳機能。翻訳元データソースがわからなくてもAPIが自動的に判別してターゲット言語に翻訳可能。NMTモデルとPBMTモデルがある。
（デフォルトではNMTモデルで翻訳元→翻訳先の組み合わせがサポートされない場合はPBMTモデルが適用される。）
NMTモデルのほうがより長い文章に対して品質の高い翻訳結果を示す。

【Cloud Speech API】
音声データをテキストデータに変換。
同区時データに対応する機械学習モデルのカスタマイズはできないが、特定の文脈に合わせて出現する可能性の高い語句をあらかじめヒントとして登録することで認識制度を高めることができる。

【Cloud Vision API】
画像データを解析して情報の抽出や分類を行う。
検出の戻り値として検出した物体の画像内での位置情報を返すためこれを使って目的の画像を抽出する、なども可能。
（例１：光学式文字認識（OCR)
画像に移っているテキストを検出する）
（例２：画像属性の検出：
画像のドミナントカラー（全体の印象を左右する色）と総ピクセル数に対するパーセントを取得する。）

【Cloud Video Intelligenc API】
動画を解析し検出する。Vision APIと同様に映っている物体を検出したり特定の物体の写っている部分のみ切り出したり、が可能。

【利用における考え方】
汎用的なデータ処理に関しては基本的に世界中のデータを収集・解析しているクラウド事業者が最も優れた機械学習モデルを作成できるものと考えらえれる。しかもクラウド事業者は日々改善・機能追加を行っている。自社のアプリケーションで解決したい問題が特にないのであればクラウドサービスを利用すればよく、同じような機械学習モデルを再開発する必要はない。
（これはOSSが普及したのも同じ要因といえる。誰にもできない正規の発明は天才に任せる。）
一方で、解決したい問題が世の中にあふれている汎用的なデータとは異なるものを対象にしている場合、こうしたAPIサービスをいくら探しても、他社に対して競争力のある結果までは得られない。その場合は自社が蓄積しているデータを用いて機械学習モデルの作成に挑戦する必要がある。

独自モデル作成支援サービス

【Cloud Machine Learning Engine】
以下、ML EngineはGoogleの機械学習フレームワークTensorFlowをGCP上のフルマネージドなインフラ環境で利用し簡単に機械学習モデルを作成・実行できるサービス。
TensorFlowはOSSのソフトウェアライブラリでオンプレミスのサーバにインストールして使用することも可能。
Datalab内にもインストールされているため機械学習プログラムの開発・実行は簡単に試すことができる。一方で大規模な機械学習タスクでは大量の計算リソースを必要とし、GPU搭載や大量の計算ノードによるクラスタを活用して行列演算を並列高速処理することが必要になってくる。
計算リソースの設計・構築はやや煩雑なものとなっているが、ML Engineを使うと計算インフラを意識せずに使うことができ、利用者はデータの準備と機械学習プログラムの作成・作成したモデルの実行・評価に注力できる。
利用方法例：
①GCP上で学習用リソースを構築してTensorFlowで書かれた学習プログラムを実行する
②学習済みモデルをAPI化して道データに対する予測を実行する

ML Engineはインフラリソースを極力隠蔽しているため、GCPコンソールのML Engine画面は非常にシンプルである（少し残念だが）
学習実行する「ジョブ」
生成される「モデル」
を管理するインタフェースのみ提供される。

【料金の考え方】
学習ジョブの実行と、モデルを使った予測の実行に対して料金が発生する。クラウド内の機械学習リソース（ジョブやモデル）の管理に対しては課金されない。
トレーニングジョブの実行に対する料金あｈ学習に利用する計算リソースの利用料を示す「トレーニングユニット」ごとに課金される。その料金はさらに事前に指定するスケール改装によってきまる。

【アクセス制御】
ML Engineではフルマネージドな独立した環境で自動的に生成・削除されるため外部からのアクセス制御を考慮しなくてよい。インプットの学習データやパッケージはデータの配置場所（Cloud StorageやCompute Engine インスタンスなど）を適切に指定すればよい。
ジョブ・モデルへのアクセスはCloud IAMを使用。

アルファ版のCloud AutoML

利用者が独自の機械学習を実行するための新しいサービス。ML Engineは機械学習そのものはあくまで利用者自身が設計・実施を行う前提のサービスである。そのため利用者には機械学習に関する知識、取り扱うデータに対する深い知識と洞察、TensorFlowの知識が求められる。
一方でGoogleがAIの民主化をうたうように世界でさらに機械学習活用をひろめるには機械学習に関する人材が不足している企業でも簡単に利用できるようにしていく必要がある。これを実現しようとしているのがCloud AutoML

第一弾として発表されたCloud AutoML Visionは画像データに対するラベル検出を処理する独自モデルの作成を支援してくれるサービス。
利用者は学習させたい画像データセットを用意してアップロードしたうえで、個々の画像に含まれるエンティティのラベルを入力・登録するだけでよい。Cloud AutoMLは入力された画像データとラベル情報を正解データとして自動的に機械学習を実行し、そのデータに対する独自の学習モデルを生成してくれる。普通に機械学習を行う場合に、前もって必要となる画像データの加工やノイズ除去などの下準備と、機械学習プログラムを試行錯誤して制度の高い学習モデルを設計する部分の作業をGoogleが肩代わりしてくれる。

こうしたサービスは一方で、独自の高い精度をめざすためのこまかなチューニングはできず、自由度は低い。しかし機械学習の知識がなくても正解データを用意するだけで一定以上の品質で独自モデルを作成することが期待される。

７章　アカウント/請求管理の概要

GCPの利用にはプロジェクトの作成と請求アカウントの紐づけが必要。GCPではCloud IAM（Identity and Access Management)の機能ｗ利用し作成したGCPプロジェクトのリソースを使用する利用者のGoogleアカウントの登録と登録したGoogleアカウントの捜査権限を設定する。通常作成したアカウント自身がプロジェクトオーナーとなり使用する利用者を招待する。ただ操作は柔軟で複数のオーナーを設定したり、請求アカウントの管理権限の身を持つアカウントを用意することも可能（オンライン経理係的な）。

【請求管理機能】
予算管理と、それに対するアラート機能、課金データのエクスポート機能がある。
予算作成：突き当りの予算を作成して起き利用額が一定になるとアラートメールを送る設定にできる。ただ注意する点は利用額が一定を超えてもGCPの利用を強制的には停止しないこと。急激なアクセスなどで突発的に料金が上がっても想定外の請求を回避できない。管理方法には工夫が必要。（月半ばで50％までいっているかチェック、など。）
課金データエクスポート：日々の課金データがCloud StorageバケットやBigQueryデータセットに自動でエクスポートされる。エクスポート先としてCloud Storageバケットを指定した場合はオブジェクトのアタマに接頭辞をつけることができ、Csv,json形式で保存可能。BigQueryの場合はデータをダウンロードしなくてもBigQuery上に保存されるためそのまま分析できる。プロジェクト・リソースごとの使用量を可視化し傾向分析に役立てることができる。

Cloud IAM

クラウド上のリソースを操作するための権限を制御できる。

【基本概念】
誰が（Member Identity）がどのようなアクセス権（Roles)でどのGCPリソースに対して権限を持つかを定義しGCP上のリソースに対するアクセスを制御できる。これの定義の集合をCloud IAM Policyとして定義している。

【用いるアカウント】
・Gsuiteドメイン
会社などの一つの組織に所属するようなすべてのメンバーを含む仮想グループ。

・Cloud　Identityドメイン
Gsuiteドメインと同様に１つの組織内のすべてのメンバーを含む仮想グループ。GmailやドライブなどのGsuiteサービスを必要としないユーザ向けのドメイン。

【アクセス制御】
それぞれのIDに対してCloud IAMで役割（Role)を割り当てる必要がある。３つの役割が存在する

・Primitive Roles
プロジェクトレベルで付与する役割。

・Predifined roles
Googleにより事前に定義されGCPの個々のリソースレベルで付与する役割。
例：AppEngine管理者を付与することでAppEngineすべてのアプリケーション設定のread/write/editの権限が与えられえる。

・Custom roles
Googleにより事前に定義したPredifined rolesとは別に個別に作成する役割。GCPプロジェクト内のメンバーやサービスアカウントに付与できる。一部組織単位でも作成可能。

基本的にはGCPプロジェクトを管理する担当者は数人に絞り開発者はPredifined rolesにより利用すべきリソースに絞って役割を付与するといい。そうすればプロジェクト内の権限を管理する上で運用が煩雑にならずリソースレベルでの権限管理が行える。

【サービスアカウント】
Googleアカウントなどと同様にCloud IAMによるアクセス権限制限ができるアカウントである。個々のエンドユーザではなくGCPアプリケーションの属するアカウントであり、アプリケーションを実行する際にユーザを介さずに各APIを呼び出すことができる。

【GCPにおける監査証跡】
Cloud Audit Loggingではプロジェクトごとに管理アクティビティとデータアクセスという２種の監査ログが取得される。取得した監査ログの表示はGCPプロジェクトのアクティビティ画面、Stackdriver　Loggingのログビュワーなどを使って確認できる。また、取得した監査ログをCloud Storageなどへエクスポートも可能。保持期間には上限があるのでログ保存ポリシーと照らし合わせ別の場所へエクスポートして保存する必要がある。


…長くなっておりますが、おそらく次がラストです。
頑張ります。