投稿者: datacompany.jp

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する④

FTPサーバにあるデータをGoogle Cloudに連携する④

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する③

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Integration Connectorsについて、ご紹介いたします。

Integration Connectorsは、SaaSなど外部サービスとGoogle Cloudをつなぐ接続アダプタです。

接続に特化したサービスで、Application Integrationと組み合わせて使います。

アダプタとしてFTPサーバの認証情報を保有し、Application Integrationでバッチ実行やワークフローを構築します。

プログラミング不要で手軽にGUIで構築できます。

その反面、デメリットもあります。

アダプタとして接続ノードを維持するため、常に稼働費用が発生します。

GUIで手軽に構築したり、POCで一時的に使いたい場合に向いています。

このようにFTPと連携する方法は、様々です。

開発リソースやコスト等の要件にあわせて選択すると良いです。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金
Google Cloud Run大稼働時のみ
Integration Connectors小常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する③

FTPサーバにあるデータをGoogle Cloudに連携する③

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する②

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Google Cloud Runについて、ご紹介いたします。

Cloud Runは、Google Cloudでコンテナ（Docker）をサーバレスに実行できる環境です。

前回のGoogle Compute Engine（GCE）は、サーバを立てる必要がありました。

Cloud Runは、サーバレスな実行環境で、コードを置くだけで動きます。

サーバレスでOS管理も不要です。

Cloud Schedulerと連携させることで、指定した時間だけ定期実行できます。

とても使い勝手が良いです。

また、コスト面でも優秀です。

Cloud Data FusionやGCEのように常時課金ではありません。

実際に稼働した時間だけ課金となり、定期実行においても、運用費を抑制できます。

その反面、デメリットもあります。

前回とりあげたGCEのように、初期構築に相応の知識や経験が必要です。

Cloud Runはプログラムやコンテナの実装が必要です。

また、タイムアウトが短く、大容量データや長時間のデータ連携には向いていません。

プログラミング等に抵抗がなく、FTPのデータ容量が比較的小さい場合に向いています。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金
Google Cloud Run大稼働時のみ

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する②

FTPサーバにあるデータをGoogle Cloudに連携する②

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する①

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Google Compute Engine (GCE)について、ご紹介いたします。

GCEは、Google Cloud上で使える「仮想サーバ」です。

アプリを常時稼働させるWebサーバや、バッチ処理の実行、ETL処理など、柔軟に環境を構築できます。

例えば、FTPから出力のみ許されているような場合（FTPへのアクセス参照が許されない場合）でも、FTPサーバの受け皿として機能します。

とても柔軟に構築できる反面、デメリットもあります。

前回とりあげたCloud Data Fusionのように、容易に構築できるとは言えず、初期構築に相応の知識や経験が必要です。

OSの運用保守やセキュリティ管理、プロセス監視など、運用の内製や工数も必要です。

Cloud Data Fusionと同様に待機中のコストもかかります。

Cloud Data Fusionも、裏側ではGCEが稼働しており、データ量が0ゼロでも費用は発生します。

GCEのインスタンスを立てている間、ずっと課金されてしまいます。

FTPサーバへのアクセスが許されず、FTPからをGoogle Cloudに連携させたい等に向いています。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する①

FTPサーバにあるデータをGoogle Cloudに連携する①

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

FTPサーバは使い勝手が良い

まず、FTPサーバについてです。

FTPサーバは、ファイルをネットワーク経由でやりとりするための仕組みです。

FTP（File Transfer Protocol）という通信ルールを使い、ファイルをアップロードしたりダウンロードできます。

企業様においては、社内基盤のサーバ間でCSVファイル等をやり取りする際によく使われます。

FTPと聞くと、少し古いイメージがありますが、私の印象では、まだまだ現役のイメージがあります。

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、方法の1つである「Cloud Data Fusion」について、ご紹介いたします。

Cloud Data Fusionは、外部ソースとGoogle Cloudを連携できるノーコードツールで、ETL / ELT パイプラインを簡単に構築できます。

ノーコードで簡単にできますが、本番運用を想定したBasic以上の利用料は月間約$1,100～です。

$1=150円として月16.5万円、年約200万円もかかり高額です。

この費用は、データ量が0ゼロでも発生します。

Cloud Data Fusionは、裏側でGoogle Compute Engine (GCE)に仮想サーバを立てています。

そのため、インスタンスを立てている間、ずっと課金されてしまいます。

FTPサーバにあるデータを、短期間でGoogle Cloudに連携させたい時や、一度限りの連携等に向いていると思います。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

会計ソフトfreeeのデータをBigQueryに連携する

会計ソフトfreeeのデータをBigQueryに連携する

・会計ソフトは、売上や経費の計上、入金と請求の消込みなど、経理業務を効率化できる
・ただ、会計データを横断的に分析したり、次の施策検討に活用するには機能が十分とは言えない
・freeeはAPIを公開しており、取引データをGoogle Cloud Run Functionsで取得し、BigQueryに同期できる
・OAuth認証で取得したトークンはSecret Managerで安全に管理する

会計ソフトは売上や経費の計上だけでなく、消込み（取引先からの入金と請求を名寄せする処理）もできる便利なSaaSです。

経理業務が劇的に効率化します。

ただ、会計データを分析したり、そこからネクストアクションを検討することは、まだまだ十分ではありません。

会計データをダウンロードして、BIに取り込めば分析できますが、そもそもデータを分析に適した形式でダウンロードできない場合もあります。

そこで、会計ソフトfreeeを例に、データをBigQueryに連携してみました。

会計ソフトfreeeのAPIは公開されている

freeeのホームページを検索すると、APIリファレンスが公開されていました。

アカウントや申請情報、銀行口座連携など、たくさんありそうです。

リファレンスを下にスクロールすると、Deals　取引（収入・支出）というものを見つけました。

内容を見ると、おそらくこれをBigQueryに連携すれば、ある程度のデータが見れそうです。

Deals　取引（収入・支出）のAPIリファレンス

発生日や金額、収入・支出フラグなど、取引の詳細なデータを取得できます。

Google Cloud Run Functionsでfreeeに接続する

freeeの取引データは、Google Cloud Run Functionsで接続できます。

freeeのOAuth連携を行い、freeeの取引（deals）を取得して、BigQueryにテーブルとして同期します。

freeeの認可画面へリダイレクトしてOAuthを開始し、freeeから返ってきたcodeを使ってtoken交換し、refresh_tokenをSecret Managerに保存します。

初めて接続した時は、Secret Managerを使わなかったのですが、最終的に使うことになった理由は後述します。

そして、freee APIを叩いてデータを取得し、freeeの取引一覧（deals）を期間指定で全件取得して、BigQueryに同期します。

BigQueryに同期したfreeeの取引データ

トークンのエラー沼にご注意

連携は成功しましたが、翌日にデータを更新すると、エラーになりました。

{'error': 'invalid_grant', 'error_description': '指定された認可グラントは不正か、有効期限切れか、無効か、リダイレクトURIが異なるか、もしくは別のクライアントに適用されています。'}

どうやら認証エラーが発生しているようです。

いろいろ検証したところ、トークンが原因でした。

refresh_tokenでaccess_tokenを取得し、access_tokenでfreee APIを呼ぶ流れになっていますが、refresh_tokenを使ってaccess_tokenを取得すると、レスポンスに新しいrefresh_tokenが返ってくることがあります。

その場合、古いrefresh_tokenを使うとエラーになります。

refresh_tokenを使い回すことはできず、最新のrefresh_tokenを常に保持しなければなりません。

refresh_tokenは、APIを実行する度に変わるとは限りません。

そのため、APIを実行し、レスポンスに新しいrefresh_tokenが含まれていたら、そのtokenを保存して更新することでエラーを回避します。

Cloud Runの環境変数にrefresh_tokenを固定せず、Secret Managerをrefresh_tokenの台帳として使うように設計することでエラーを回避できました。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

e-TaxでエラーHUBH139Eが発生した時に試すこと

e-TaxでエラーHUBH139Eが発生した時に試すこと

・マイナンバーカードやスマートフォンで国税を電子申告できる納税システム「e-Tax」
・個人の確定申告から法人税まで、スマートフォンの電子証明書で簡単に申告できる
・ただし、マイナンバーカードを更新すると、e-Taxに登録済みの電子証明書と異なりエラーが発生する場合がある
・e-Taxの電子証明書を更新する時に、スマートフォンのマイナンバーカードで署名せず、実物のマイナンバーカードで署名を試す

今回は、クラウドや生成AIではなく、e-Taxのお話です。

e-Taxは、マイナンバーカードやiPhone等のスマートフォンで国税を電子申告できる納税システムです。

個人の確定申告から法人税まで、スマートフォンの電子証明書で簡単に申告できることから、使ってらっしゃる方も多いと思います。

今回は、マイナンバーカードを更新したことで申告エラーが発生したものの、いつもと違うリンクをタップすることで解決したお話になります。

同じようにお困りの方もいらっしゃると思いますので、ご参考になれば幸いです。

見慣れないエラーHUBH139Eが発生

e-Taxは、個人の時から使っており、スマートフォンで確定申告していました。

スマートフォンにマイナンバーカードを取り込み、電子証明書として使えるようになってから利便性もさらに高まり、使い勝手の良いサービスだと思います。

このたび、法人税を申告したところ、エラーになりました。

見慣れないエラー「HUBH139E」が発生

※画像は会計ソフトの画面。e-Taxも同じエラーを確認。

エラー情報によると、e-Taxに登録済みの電子証明書と、今回の申告に使った電子証明書が異なることが原因のようです。

個人の確定申告もe-Taxを使いましたが、最近になって、マイナンバーカードを更新したことを思い出しました。

おそらく、電子証明書も更新されており、そのことが原因だと思いました。

そこで、ヘルプページを確認し、e-Taxのマイページから電子証明書を再登録しました。

e-Taxのお知らせで、「電子証明書の登録」→「送信されたデータを受け付けました」の通知が届いたことを確認し、再度、法人税を申告しました。

しかし、同じエラーが発生し、ここで沼にはまってしまいました。

e-Taxの受信通知で、電子証明書が受け付けされたことを確認していたが、エラーになった。この通知が届くと、原則として、e-Tax側は即時反映されると聞いていたこともあり沼にはまった。

e-Taxの電子証明書を更新する時に、スマートフォンのマイナンバーカードで署名せず、実物のマイナンバーカードで署名を試す

e-Taxの電子証明書の更新は、マイページ→その他の登録情報→電子証明書の登録・更新からできます。

ここが沼にはまった原因でした。

電子証明書の各項目はスマホ用を指定

下にスクロールすると、このような画面が出てきます。

「スマートフォンを利用」をクリックすると、QRコードが表示されます。

QRコードをスマートフォンのマイナポータルアプリで読み取ると、スマートフォンに次のような画面が表示されます。

この画面が表示されたら、一番下の「実物のマイナンバーカードで署名」をタップして、電子証明書を更新します。

この方法でe-Taxの電子証明書を更新したところ、エラーHUBH139Eは解消しました。

スマートフォンにマイナンバーカードを取り込み、電子証明書として使えるようになってから、「iPhoneのマイナンバーカードで署名」を常にタップしていました。

おそらく、「iPhoneのマイナンバーカードで署名」をタップして電子証明書を登録し、e-Taxのお知らせで、「電子証明書の登録」→「送信されたデータを受け付けました」の通知が届いたとしても、古い電子証明書で上書きしたことになると思われます。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

Google Cloud Storage Transfer（ST）の限界

Google Cloud Storage Transfer（ST）の限界

・誰でも簡単にノーコードでStorage間でデータ転送できることが魅力的
・例えば、Google Cloud StorageのバケットAからバケットBに定期的に自動転送
・ただし、任意の日時で繰り返し転送できない　繰り返し設定は時間・日・週のみで、月次も不可
・工数はかかるが利便性や長期的な運用を考慮すると、Cloud Runでフルスクラッチ開発がベター
・Cloud Runなら、任意のスケジュールで転送できる

Google Cloud Storage（GCS）のようなStorage間でデータを転送したい時に役立つのがGoogle Cloud Storage Transfer（ST）です。

便利で簡単に設定できるため、バケット間でデータを転送する時など、知らないうちに利用していたという方も多いと思います。

STは、たびたびアップデートされており、AWS（S3）からGCSも転送できます。

STのユースケース　GCSのバケット間の転送

STで、よく使われているケースとして、GCSのバケット間の転送があります。

特に、KPIをトラッキングする企業様において、社内外のデータをGCSで管理されており、それらを運用して統合分析する場合に役立ちます。

実装もとても簡単です。

転送ジョブを作成します

次のステップへ進みます

ソース（転送元）を指定し次へ進みます

転送先を指定し次へ進みます

ジョブの実行タイミングを指定し次へ進みます（本日のテーマです）

お好みの設定で作成し設定完了です

STには限界もある

このように設定すると、任意のタイミングでStorage間のデータを自動で転送します。

ノーコードで簡単な操作だけで、このようなデータ転送を構築できます。

しかし、STには限界もあります。

例えば、毎月1日AM9時に1回だけ転送を設定します。

カスタム頻度で実行を選びます

頻度に「月」がないため設定できません

1時間毎や2週間毎等は設定できますが、毎月は設定できません。

そのため、任意の日時で繰り返し転送できません。

Google Cloud Run Functionsのフルスクラッチでカスタマイズ対応


このようなケースの場合、初期工数はかかりますが、Google Cloud Run Functionsのフルスクラッチ開発がベターになります。

Cloud Run Functionsなら、毎月1日AM9時に1回だけ転送といったように、任意の日時でピンポイントに転送できます。

STはデータ容量やファイル数で課金されるため、それらが多い場合の費用も抑制できます。

Cloud Run FunctionsはPythonに対応。イベント駆動で様々なケースに応じた処理がサーバレスにできる。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

VertexAIとBQMLの効率的な使い分け

VertexAIとBQMLの効率的な使い分け

・様々なデータでAIモデルを作れるVertexAI
・人気の売上予測モデルも、AutoMLにデータを読ませればノーコードで自動作成
・ただし、モデル作成は1時間あたり約$21と高額
・非公式だが、Googleが推奨する方法で、費用と精度を両立したモデル作成が可能

生成AIが全盛期ですが、従来のAIもいまだ現役です。

特に、売上予測など、日次バッチでロジックを安定して稼働させたい時に重宝します。

Google Cloudには、たくさんのAIがあります。

SQLやPythonはフルスクラッチでモデルを作れますが、ノーコードでモデルを作るVertexAIのAutoMLは人気があります。

VertexAI　AutoML　※公式ページにリンクします

VertexAIは利用料金がとても高い

VertexAIは、ノーコードでAIモデルを作れるため、誰でも簡単に扱えます。

AutoMLは、目的などを選択するだけで、データにあわせたロジックが自動で反映され、予測モデルを簡単に作れます。

しかし、一部のモデルは利用料金がとても高いです。

例えば、売上予測に必要な表形式データを読み込ませると、モデル作成は1時間あたり約$21課金されます。　

VertexAIの料金　※公式ページにリンクします

モデルを完成させるまでに、様々なパターンを試すのが一般的です。

一度で完璧なモデルができることは稀で、それはほとんど空想のレベルです。

経験則ではありますが、1つのモデルを作るまでに、100回程度は試行錯誤しています。

VertexAIは、モデル作成を実行開始してから完了するまで、とても時間がかかります。

レコード数とカラム数がまったく同じデータで試してみてください。

SQLやPythonでフルスクラッチでモデルを作成するより、明らかに時間がかかります。

仮に、モデル作成1回に1時間かかった場合、100回試行すると、100時間です。

モデル作成は1時間あたり約$21です。

$21×100=$2,100≒32.3万円課金されてしまいます。※執筆当時の為替レートで試算

これでは課金が気になり、モデルを安心して作れません。

VertexAIとBQMLの効率的な使い分け

Google Cloudには、VertexAI以外にもBQMLというAIがあります。

BQMLは、Google CloudのDWH「BigQuery」に実装されているAI機能です。

BQMLはVertexAIとも連携していますが、モデル次第では、安価にモデルを作れます。

BQMLは、時間課金ではなく、クエリ実行でスキャンしたデータ量に応じて課金されます。

つまり、「どれだけのデータを読み取ったか」に応じた課金です。

一般的に、売上予測のデータは軽量で、Byte数が大きくなることは、そうありません。

非公式　Googleが推奨する費用と精度を両立したモデル作成

仕事の関係上、Google Cloudの皆様とお話することがあります。

売上予測のデータが軽量にも関わらず、VertexAIの処理が遅くて課金に悩まされていた頃、原因調査と改善を依頼したことがありました。

調査しても原因は不明で、VertexAIを使うと、処理に時間がかかってしまします。

そこで、以下のような処理を試したところ、費用と精度を両立してモデルを作成できました。

BQMLも、以前より、精度や機能が格段にレベルアップしています。

以前のBQMLに満足できなかった方も、お試しされてはいかがでしょうか。

フルスクラッチにはなりますが、皆様のご参考になれば幸いです。

・まず、VertexAIで最初のモデルを作ります。
・モデルができたら、特徴量をチェックします。
・VertexAIが選んだ特徴量を参考に、BQMLでモデルを再現します。
・モデルを再現したら、お好みの精度になるまで、BQMLでモデルを更新します。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

Cloud Data Fusionがスケジュール実行エラーした時の対処法

Cloud Data Fusionがスケジュール実行エラーした時の対処法

・外部ソースとGoogle Cloudのパイプラインをノーコードで構築できるCloud Data Fusion
・設定済みのスケジュールタスクにおいて、エラーが発生することがある
・スケジュール設定を見直すだけで解決する場合がある

SalesforceやAWSのRedshift等の外部ソースをGoogle Cloudへ連携する方法はいくつかありますが、最も簡単でメジャーな方法はCloud Data Fusionです。

Cloud Data Fusionは、外部ソースとGoogle BigQueryなどGoogle Cloudを連携できるノーコードツールで、パイプラインを簡単に構築できます。

インスタンスを作成することで、毎日およそ数十ドルのコストが発生しますが、とても簡単にパイプラインを構築できるので、利用されている企業様も多いです。

Cloud Data Fusion公式

成功したはずのデプロイが、スケジュール実行するとエラーになる

簡単にパイプラインを構築できるCloud Data Fusionは、デプロイしたパイプラインをスケジュール設定することで、簡単にバッチ化できます。

しかし、デプロイに成功したはずのパイプラインを、スケジュール実行すると、エラーになる場合があります。

エラーになったログをダウンロードして確認すると、以下のようなキーワードが出力されます。

Spark Program　'phase-1' failed

Cloud Data Fusionは、複数のステップを踏んで、外部ソースをGoogle Cloudに連携します。

このエラーは、’pahse-1’で失敗しており、そのエラーメッセージの付近に、このような記述もあります。

Caused by ...省略... The connection attempt failed.

接続に失敗したというエラーが発生しています。

このエラーは、外部ソースへの接続情報やファイヤーウォールなど設定関連が誤っている時に発生します。

でも、おかしいですよね。

デプロイに成功しています。

設定は正しいので、エラーになるはずがありません。

高負荷の処理が集中すると、外部ソースもCloud Data Fusionもリソースがひっ迫してエラーになりやすい

Cloud Data Fusionは、同時に複数のデプロイを実行できます。

その上限は開示されていませんが、おそらくCloud Data Fusionのバージョンや、インスタンスのエディション等で異なります。

私の経験上ではありますが、現行のBasicエディションであれば、50個程度は実行できたと思います。

しかし、スケジュール設定においては、最大で10個しか同時に実行できません。

これは、同時実行数を減らすことで、高負荷の処理を分散する意図だと思われます。

おそらく、10個同時にスケジュール実行したことで、リソースがひっ迫し、エラーになったようです。

スケジュール設定を見直すだけで解決する場合がある

10個同時に実行してダメな場合、同時実行数を減らさなければなりません。

しかし、デプロイ数が多い場合、同時実行数を１つに設定してしまうと、全体の処理が終わらず、データ更新が終わりません。

もし、100個のデプロイをスケジュールしたい場合、100個を１つずつ実行するので、相当な時間がかかります。

このような場合、以下のように設定を見直すだけで、解決する場合があります。

10個同時に実行する点においては、外部ソースやCloud Data Fusionへの負荷がかかる点は変わらず、根本的な解決にはなりませんが、起動処理などのタイミングをずらすことはできます。

変更前

デプロイ番号スケジュール　開始時刻
#1~#100:00AM
#11~201:00AM
・・・省略・・・
#91~#1009:00AM

変更後

デプロイ番号スケジュール　開始時刻
#10:00AM
#20:06AM
・・・省略・・・
#919:00AM
・・・省略・・・
#1009:54AM

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

MMMが失敗する典型的なパターン

MMMが失敗する典型的なパターン

・デジタルやオフライン広告の予算配分を最適化できるMMM（マーケティング・ミックス・モデリング）
・MMMへの誤解。MMMは優れた手法だが、万能薬ではない
・広告主側のデータ特性や結果の判断も重要。
・MMMを導入しても失敗する典型的なパターンをご紹介

「WEB広告とTVCM　どちらにお金を使うべきかわからない」

「デジタル広告とオフライン施策　最適な予算配分がわからない」

これらは、WEB広告などデジタル広告と、TVCMを中心としたオフライン広告を併用している企業様において、よくあるお困りごとです。

そのような企業様においては、MMMが有効な判断材料になります。

デジタルやオフライン広告の予算配分を最適化できるMMM

MMMは、TVCMやデジタル広告、プロモーションなど複数のマーケティング施策が、売上や利益にどのように影響を与えるかを定量的に分析し、予算配分を最適化する手法です。

既存の手法と異なり、メディア横断での分析により、公平・客観的に評価し、予算配分を最適化します。

3rdPartyCookie規制等により、広告効果のトラックが難しいことも背景に近年注目されています。

しかし、MMMを導入しても、失敗する場合があります。

弊社の過去の事例をもとに、典型的なパターンをご紹介いたします。

MMMへの誤解

MMMは広告手法の効果を可視化し、各予算を最適化できる優れた手法です。

しかし、万能ではありません。

まず、背景として、MMMへの過度の期待と誤解があります。

よくある誤解としては、次のようなものがあります。

「MMMがあれば全部わかる」

「MMMがあれば、予算最適化もキャンペーン施策も完璧に最適化できる」というわけではありません。

MMMは、過去データに基づく統計的な推定です。

因果関係は確定できません。

シナリオ設計や意思決定の補助ツールと考えるのが適切です。

「MMMは短期施策の効果も測れる」

「MMMは、日次やキャンペーン単位で効果を判定できる」というわけではありません。

MMMは、週次の集計データを用いるケースが多いです。

日次データは、サンプル数が多く確保できる反面、データのぶれも大きくなり、結果として、予測精度もぶれやすくなります。

一般的には、2年程度のデータが必要で、それらを週次に変換して分析します。

日次単位や短期的な細かい効果測定には不向きです。

それらを求めるならA/Bテスト等が適切です。

広告データの特性や、分析結果の判断も重要

MMMの制約や効果を理解して分析しても、失敗する場合があります。

「広告主様のデータに大きな偏りがある」

例えば、TVCM、GDN、YDAを出稿しているものの、TVCMの出稿期間が極端に少ない場合等です。

このような場合、TVCMのデータに欠損が多く、TVCMの効果を適切に評価できません。

各メディアの出稿頻度に、なるべく偏りがないことが望ましいです。

「分析結果を受け入れられない個別の事情がある」

MMMの分析結果は、必ず正しいわけではありませんが、統計に基づくもので、人間の直感を排除した客観的な評価になります。

多くの場合、分析結果は担当者様の直感に近しいように思いますが、分析結果を受け入れられない個別の事情がある場合、MMMは成功しません。

前述の広告データの偏りにも関連しますが、例えば、広告予算5,000万円のうち、TVCMが4,000万円で、残りがデジタル広告といったように、予算配分に大きな偏りがある場合です。

このような場合、広告主様が予算を最適化しづらい個別の事情を抱えていることがあります。

このケースの場合、TVCMの予算が多すぎることを担当者様は感じながらも、MMMで最適化を試みたが、個別の事情があるがために客観的な結果も受け入れられず、ダイレクトな予算アロケーションができないといった具合です。

そのような場合、弊社ではMMMの効果が見込めないため、個別の事情が解決するまでの間、MMMは中止することをお勧めしております。

Google Cloud開発お承ります

datacompanyでは、MMMのSaaS「MMMトラッカー」やGoogleの最新MMM「Meridian」の受託分析をはじめ、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

Proudly powered by WordPress