👌

Google Cloud 内製化 Day : Day 2

2022/08/29に公開

Google Cloud

tech

はじめに

今回は、2022年7月7日に行われたシステム内製化のためのセミナー、Google Cloud 内製化 Day : Day 2に参加したので、そちらがどのような内容であったかと学んだことについての記事をまとめる。

セッション１ : Smart Fuctory（IIoT Platform）誕生秘話と今後の展望

パナソニック　インフォメーションシステムズ　IoT・DXソリューションセンター　作本直樹　さん

パナソニック全社のDXを進めていて、IoT・DXソリューションセンターではそれぞれ製品IoT、製造IoTをミッションとしたチームがある。今回は、製造IoTのIIoT-PFについて説明する。

IIoTとは

つなぐ
集める
ためる・つかう

を実現するプラットフォーム。具体的には、現場システム、モノづくりをするコントローラーあるいは生産制御システムからデータを集め、それを人を介さず別のシステムにつなげ、加工・変換したり蓄積、表示、リアルタイム分析するためのものである。

IIoTをどのように進めたか

どのようなプラットフォームが欲しいか

国内外の様々な工場にヒアリングをして、どのようなプラットフォームにしていけばよいか検討した。挙がった要件としてはこのようなものがある。

生産技術や設備担当が自由にデータ利活用したい
リアルタイム(msec、sec)に発生するデータを集めたい
データとアプリケーションを分離したい
データをつかった生産や品質、設備管理をしたい

このような要件から、お客様自身で有効に利活用できるプラットフォームが欲しいと結論付けた。具体的には、以下のようなことが必要だと考えた。

同一アプリを複数環境で使うアーキテクチャ（種類の異なるデータを同じように扱う）
データは常に発生するため、クラウドだけでなくオンプレミスとのハイブリッド
サードパーティアプリケーション（現場ツール）
新しいツール（バージョン）を利用可能
生産や設備部門と一緒にプラットフォーム（内製化）を考える

どのように作っていくか

そこで、このプラットフォームをどのように作るか検討するため、国内外のIoTプラットフォームをベンチマークした結果、満足するプラットフォームは内製化でないと手に入らないと考えた。内製化する必要がある項目としては、以下の点が挙げられた。

クラウドとオンプレミスのハイブリッド
統合的なコンテナ管理
データレイク、データウェアハウス、データマート
大量データのデータ変換・データ収集
プラットフォームを一元的に運用管理

IIoTプラットフォームの変遷と現状

以下のような過程を経て、現在のIIoTプラットフォームができた。

オンプレミス
アプリケーション、ミドルウェア、OS、物理サーバー
仮想環境
アプリケーション、ミドルウェア、OS、仮想サーバー・物理サーバー
IIoT-PF 0.1
アプリケーション、ミドルウェア、コンテナ、OS、物理サーバーorクラウド
IIoT-PF 1.0（現在）
アプリケーション、ミドルウェア、コンテナ、OS、物理サーバーorクラウド
機能...収集（約96万件/分）、加工・変換、可視化（ダッシュボード）、エッジ・クラウド

課題として、処理量を増やすことが挙げられている。

これからどのようにすすめるか

これから方向性をアーキテクチャの弱点克服、美点拡大とし、課題を以下のように整理した。

1分間に約100万件
蓄積前（ストリーム内）にデータ処理する必要
集められたデータを時間内に処理する仕組み
発生点（デバイス）や収集点（エッジ）では、処理が追い付かない
データストア（データベース）の最適化

その上で、次のIIoT-PF 2.0では、

エッジ側での大量分析、クラウド側でのリアルタイム分析機能の追加
エッジでのリアルタイムデータ収集性能向上

を達成するため、課題は以下が挙げられた。

性能検証方法
スケールアウト方法
どのようにアーキテクチャを変えていくか

まとめ

これからのIIoT-PFは

さらなる内製化
最適なプロバイダ・サービスを使う
クラウドとエッジを最大限に利活用
優秀なスペシャリストとのテクニカルセッション

をすることで、様々なユーザーへサービス提供できるものを目指す。

セッション２ : 実践！Cloud Run セキュリティ

Google Cloud アプリケーションモダナイゼーションスペシャリスト　内間和季　さん

Cloud Runのセキュリティについて説明する。

Cloud Runとは

フルマネージドなコンテナ実行環境で、いわゆるサーバーレスといわれるプロダクトである。
特徴としては以下がある。

高速なデプロイ
サーバーレス・ネイティブ（管理するサーバーなし、コードに集中できる）
高いポータビリティ

基本的なアクセス制御機能

以下の4つがある。

IAMによるアクセス制御
誰がアクセスできるか
サービス個別のサービスアカウント
各サービスが何にアクセスできるか
Ingress設定
どの経路でサービスにアクセスできるか
Egress設定
どの経路で他のサービスにアクセスできるか

これらについて詳しく説明する。

IAMによるアクセス制御

サービスデプロイ時にrun.invokerというロールが付与されているユーザーのみアクセスを許可するように設定できる。

サービス個別のサービスアカウント

Cloud Runのサービス単位でサービスアカウントを設定可能。これは他のGoogle Cloudサービスへのアクセス制御で活用できる。

Ingress設定

Cloud Runサービスに対するアクセス経路を制御できる。以下の3種類から選択できる。

すべてのトラフィックを許可する
内部トラフィックのみ許可する
内部トラフィックとCloud Load Balancingからのトラフィックを許可する

Egress設定

宛先IPアドレス種別に応じてCloud Runから送信されるトラフィックの経路を制御できる。以下の2種類から選択できる。

プライベートIPアドレスレンジの宛先のみVPCコネクタ経由
すべての送信トラフィックをVPCコネクタ経由

Cloud Run セキュリティ全体像

以下の3つの観点について説明する。

ユーザーアクセスの制御
サービス間通信の制御
ワークロードの保護

ユーザーアクセスの制御

ユーザーアクセスの特性に応じて、経路や権限を絞り、攻撃の機会を少なくすることができる。

外部ユーザーからのアクセス

インターネットを通じて不特定多数（悪意のあるユーザーを含む）からのアクセスが発生する。こちらに対しては、Cloud Armorという機能をインテグレーションすることによって、エッジでのセキュリティ保護（DDoS保護、WAF）が可能になる。
また、Ingress設定として「内部トラフィックとCloud Load Balancingからのトラフィックを許可する」を選択することにより、直接Cloud Run上のサービスにアクセスすることを防ぐことが可能。

内部ユーザーからのアクセス

利用者が限定されるシステム（社内システム等）の場合は、Identity Aware Proxy(IAP) 等の認証機能を組み込むことで安全にサービスを公開できる。
また、オフィスやデータセンターからCloud InterconnectやCloud VPNを用いたアクセスが可能な場合は、Internal HTTP(S) Load BalancingやPrivate Service Connect(PSC) を使ってプライベートな経路でのサービスアクセス実現できる。

プライベートな経路でのアクセス

プライベートな経路でCloud Runサービスにアクセスさせる際の主な選択肢は2つある。

Internal HTTP(S) LOad Balancing
カスタムドメインを設定したい、単一URLに複数のサービスを紐づけたい
Private Service Connect
デフォルトドメイン（*.run.app）を利用する場合

サービス間通信の制御

Cloud Runの通信相手となるサービスの種類によって検討ポイントが異なる。

他のGoogle Cloudサービスとの通信

サービスアカウントにより、他Google Cloudサービスへのアクセス制御を実現する。デフォルトのサービスアカウント（Compute Engineのデフォルトサービスアカウント）は強い権限を持っているため、サービス単位で最小権限が付与されたサービスアカウントを作成・設定することを推奨。

VPC内リソースと通信

サーバーレスアクセスコネクタを使うことで実現可能。サーバーレスVPCアクセスコネクタは共有VPCへの接続もサポート。

Cloud Runサービス間の通信

バックエンドサービス等で呼び出し元を制限したいケースでは、サービス作成時に「認証が必要」を選択することで、IAMによる認可を有効化できる。

3rd Partyサービスへの通信

3rd Partyサービス側でIPアドレスベースのアクセス制御を行っているようなケースでは、Cloud Runから送信するトラフィックのIPアドレスを固定する必要がある。
Egress設定で 「すべてのトラフィックをVPCコネクタ経由でルーティングする」 を選択し、Cloud RunからのEgressトラフィックをすべてCloud NATを経由させて外部サービスへアクセスすることでEgress IPアドレスの固定を実現。

3rd Partyからのアクセス

オンプレミスや3rd PartyサービスなどGoogle Cloud外部からWorkload Identity Federationを使いService Account Keyをダウンロードせずに認証付きアクセスが可能。

ワークロードの保護

セキュアなソフトウェアサプライチェーンの一例として

Google提供のベースイメージを使う
イメージ脆弱性スキャンをする
バイナリ認可機能を使う

Google提供のベースイメージ

定期的な脆弱性スキャンが実行され、最新のセキュリティパッチが自動的に適用されたベースイメージを提供する。
また、distrolessのような軽量のイメージを利用することで攻撃対象領域を小さくすることも可能。

Container Analysis

Common Vulnerabilities and Exposures(CVE)データを取得し、コンテナイメージの脆弱性の重大度（５段階）を判定する。
リポジトリのイメージPush時やオンデマンドでの脆弱性スキャンをサポート。

Binary Authorization

信頼できるコンテナイメージのみがCloud Runにデプロイされることを保証する。以下の条件に当てはまるコンテナイメージのみデプロイを許可するよう制御が可能。

イメージに対する認証者による証明書が存在する
またはイメージ名が許可リストにマッチする

また、Binary Authorizationポリシーというものを以下から設定する。

すべてのイメージを許可
すべてのイメージを禁止
証明書を要求

Secret Manager

機密情報をセキュアに管理可能。
シークレットはボリュームとしてマウントするか、環境変数に設定することができる。
アクセス制限はIAMで制御する。

より厳密に制御する

VPC Service Controls

以下のようなリスクを低減できる。

悪意のある内部関係者や感染コードによるデータ持ち出し
盗まれた認証情報を使用し、無許可のネットワークからCloud Runサービスをデプロイ/更新

組織ポリシーによる強制

Cloud Runの各種設定を強制させることが可能になる。

Ingress設定
Egress設定
Binary Authorization有効化

最後に

サーバーレスは簡単にサービスを公開できる反面、使用を知らずに運用していると思わぬセキュリティインシデントが発生するリスクもある。
Cloud Runにはセキュリティ関連の機能・周辺サービスが充実しており、またエンタープライズに求められるような柔軟な制御も可能となっている。
Cloud Runを上手に使って「開発生産性」と「セキュリティ」を両立させていきましょう

セッション３ : DX推進における内製化の 3 つのポイント

東急株式会社デジタルパットフォームリードエンジニア　許駿さん

このセッションでは、「街づくりのDX」に向けて発足した東急のURBAN HACKSというプロジェクトチームが、東急グループのDX、内製化に向けてどのように取り組んでいるかご説明していただいた。
主に、以下の3つのことに取組んでいるとのことだった。

チーム作り
開発スタイル
クラウド活用

チーム作り

東急では、内製化の目的として重視していることは柔軟でスピィーディーな対応であるとのことだった。そのため、方向性によってSoE（System of Engagement）とSoR（System of Record）2つのチームに分け、このうちSoEにおいては顧客のニーズに柔軟に対応する必要があるため、小さく検証しながら進めていけるよう内製化を推進していると説明されていた。
チーム構成としては

スムーズに動きたいため、6～9名の規模感で構成する
意思決定ができるビジネスオーナーを必ず入れる
すべての活動に責任と権限を持つように、他にプロダクトオーナー、デザイナー、エンジニアを同じチームに入れる

とすることで、素早く柔軟な動きができると話されていた。

開発スタイル

開発スタイルとしてはフラット＆アジャイルを取り入れて、

チャンス・インサイトは全員で行う
デュアルトラックアジャイル方式で、価値検証とデリバリーを高速に回す

というスタイルで進めていると話されていた。

クラウド活用

こちらでは、config controllerによるガードレールの作成について紹介していた。
まず、なぜガードレールが必要なのかをクラウドのセキュリティ上の問題に着目して説明し、その後config controllerの構成と具体的に何ができるのかの説明でミスの事前防止、修正、監査ができると説明されていた。

総括

最後に、チーム作り、開発スタイル、クラウド活用についてのまとめと、東急の宣伝をしてセッションを終了した。

セッション４ : ソフトウェア産業のトイルを駆逐するスリーシェイクの主力サービスについて

株式会社スリーシェイク Incubation 事業部プロダクトマネージャー　岩崎喬さん

こちらのセッションでは、まず内製開発のトレンドや見解をについて話された後、スリーシェイクさんの展開する３つの主力サービス

Sreake...技術戦略、設計、構築、運用までの技術支援サービス
Reckoner...あらゆるデータソースを連携し、加工や統合を行うデータパイプラインサービス
Securify Scan...手軽に何度でも脆弱性診断を実施、セキュリティレベルを可視化するサービス

についてご紹介していただいた。

内製開発のトレンド

まず、ITを活用している事業者とそうでない事業者の年商増加率を比較し、事業の成長にはIT技術が必要条件であると説明されていた。その上で、事業牽引のキードライバーとして

クラウド・コンテナ技術
アジャイル開発
SaaS活用

を挙げ、さらにそのためにエンジニアの存在すなわち内製化が必要であるとまとめていた。
トレンドの観点では、データをみることで内製開発はそこまで進んでいないが、先進的な企業とそうでない企業で内製化しているかしていないかの二極化が進んでいる、そこでスリーシェイクさんの3つのサービスで内製化を支援できると繋げていた。

Sreake、Reckoner、Securify Scanの説明

ここでは、3つのサービスがそれぞれどのようなサービスで、どのように内製化に役立つのかを紹介されていた。
まずSreakeの概要を説明し、その後SRE（Site Reliability Engineering）の原則と定義、なぜSREが求められているのか、導入するメリットを主にコスト面に着目し説明されていた。SREの実践内容は多岐にわたるため、すべてを実践することはほぼ不可能というところから、Sreakeを用いて小さく始め成功体験を積むことが重要と話されていた。
2つめにReckonerの紹介をされていた。データの統合・活用でどのようにReckonerが利用されるか説明し、内製化における利用のポイントを説明されていた。具体的には、データエンジニアリングの課題に対し、Reckonerを使うことで解決につながるという内容だった。
3つめにSecurify Scanの紹介をされていた。脆弱性診断の課題を提示し、日々発生する新しい脆弱性に向き合うためにSecurify Scanを活用し、セキュリティの知見の内製化をするよう勧めていた。

セッション５ : アプリケーションを内製化する際のデータベース選択指針

Google Cloud データベーススペシャリスト　佐藤貴彦　さん

このセッションでは、データベースの選び方についてさまざまなGoogle Cloudのデータベースサービスとその特徴について触れながらご説明いただいた。

内製化で考えなければいけないデータベースの要素

こちらでは、データベースにはさまざまな種類があるが、ではそれらをどのように選択すべきかという点について、まず選択する際に着目すべき機能要件、非機能要件について触れた。
そして、それらを管理するにはコストがかかるため、マネージドデータベースを活用しましょうという話に繋げていた。

Google Cloudのマネージドデータベースの全体解説

ここでは、6つのマネージドデータベースサービスを、商用とクラウド環境対応の2種類のデータベースに分類した後、それぞれの特徴と6つの非機能要件における性能の違いについて説明されていた。

Google Cloudのマネージドデータベースの選び方

ここでは、まず内製化向きのサービスとして6つのうちから4つを紹介し、それぞれどのような場面で活用すべきかについて具体例をもとに説明されていた。

まとめ

最後に、Google Cloudのデータベースサービスの導入する際の選択肢として、まず4つから選択し、必要に応じて特化型のサービスを使いましょうということでこのセッションを終了した。

おわりに

今回は、7月7日に行われたGoogle Cloud 内製化　DayのDay 2における5セッションの説明内容をまとめた。
開発のどの部分をどのように内製化すべきかを検討することが重要であると感じた。