2020-09-28

コロナ禍での情シスの対応とそこから見えたもの

はじめに

こんにちは！オールアバウトナビ、システム部の@k_shiotaです。

オールアバウトには業務全体に関わる部署、情報システムG（情シス）が存在します。
その情シスの皆さんに、「コロナの対応」について、社内で行っているLT会にて発表いただきました！

今回は情シスでのコロナ対応について発表をしてもらいましたので、このブログで紹介したいと思います。

基本在宅勤務になって情シスの業務に変化がありました。情シスは一緒のフロアにいたため、相談をしやすく都度対応してもらうことが多かったのですが手順書を作成して困ることが少なくなり、困ったことはslackでオープンに相談することで、他の方も同様な問題があった時に参考になったかと思います。

f:id:allabout-techblog:20200916160129p:plain — 情シス業務の変化

slackへの投稿数は原則在宅が始まる前と後では増加しております。

f:id:allabout-techblog:20200916160211p:plain — 情シス業務の変化_slackの投稿数

変化の中で見えてきたもの

固定電話が必要かどうかについて、以前からも話題に上がっていたのですが今回の件でどうにかなるという事もわかり良い判断材料となりました。

f:id:allabout-techblog:20200916160256p:plain — 変化から見えてきたもの

また、ゼロトラスト環境に移行することに待ったがない状態になりました。

f:id:allabout-techblog:20200916160319p:plain — 変化から見えてきたもの_ゼロトラストセキュリティモデル

今後の計画

f:id:allabout-techblog:20200916160358p:plain — 今後の計画

slackでの問い合わせに一つ一つ答えているため、定型化したものをボット化してその他の業務に当たれる時間をふやすこと
ゼロトラスト環境は社外からのアクセスが増えるため強化する必要があること
固定電話は不要でスマホを全社員に配布することなど、在宅勤務環境をより良くしていくよう動いて行くとのことです。

最後に

f:id:allabout-techblog:20200925160036p:plain — 最後に

会議の時間が超過する問題はどうしてもあるようでして、切実なお願いでした。自分も今後気をつけていきたいと思います。。。

まとめ

弊社でもコロナ前から在宅勤務を導入しておりましたが、まだまだやりづらい点があったかと思います。
原則在宅勤務となり、在宅勤務の環境を整えることが急務となりました。

原則在宅勤務が始まったことで対応に追われて大変だったとのことですが、今は落ち着き更に働きやすい環境を整えているとのことです。
普段から頼っている情シスを更に信頼することになりました。

もし、こんな環境で働いてみたいと思ったらぜひ一緒に働きましょう！
以下より採用情報がありますので、募集をお待ちしております！

corp.allabout.co.jp

2020-08-27

Google Cloud Functionsを使ってバックアップデータからログの再収集を行う方法の紹介

こんにちは！オールアバウトでデータエンジニアをしている@ondaljhです。

皆さんはGoogle Cloud Functions(以降、Cloud Functions)を利用したことがありますか？自分も業務上では使ったことがなかったんですが、今回ある案件でCloud functionsを利用する機会があったので、私たちのチームでのCloud Functionsの利用シーンを紹介させていただきたいと思います。この記事を最後まで読んでいただいて、「こんな利用シーンもあるんだ～」程度で理解していただければ幸いです。

従いまして、本記事は下記のような方を想定して書かせていただきます。

Google Cloud Functionsに興味はあるが深くかかわったことがない方
Google Cloud Functionsの利用パターンを調べてる方

また、Cloud Functions以外に出てくるGoogle Cloud群についての詳細な説明は記事の最後の方に公式サイトへのリンクを貼りますので、興味ある方はぜひ見てみてください！

概要

冒頭で書いた「ある案件」とは、チームプロジェクトで「ログ収集基盤のサーバーレス化」というものがありまして、そのうちの1つである「バックアップデータからログの再収集」を意味します。

まず、ログ収集基盤のサーバーレス化の基本的なアーキテクチャをお見せします。

f:id:allabout-techblog:20200826165138p:plain — ログ収集基盤のログ転送フロー(通常)

図の通りにウェブから発生したログはGoogle Cloud Run(以降、Cloud Run)で受け入れて最終的にはTreasure DataとGoogle BigQuery(以降、BigQuery)まで流れていきます。
また、Cloud RunからGoogle Cloud Dataflow(以降、Dataflow)までのデータ転送にはネットワーク上の通信の高速化のためにProtocol Buffersを使ってデータ通信を行います。(Protocol Buffersは通信の高速化以外にもいくつかのメリットがありますが、本題とずれるので詳細については記事の最後の方に貼ってある公式サイトへのリンクをご確認ください。)
なお、Cloud Runが受け入れたログはバックアップとしてBigQueryのあるテーブルへ格納します。その際のフォーマットは、Cloud RunからGoogle Cloud Pub/sub(以降、Pubsub)へ転送する、Protocol Buffersにてシリアライズされたフォーマットのままにしてます。
このBigQueryへ格納するバックアップデータが「ログの再収集」の肝になりまして、PubsubやDataflowに障害が発生した場合、このバックアップデータからリカバリーが可能になります。

ここからが本題で、Cloud Functionsの導入に伴う下記の2点について紹介させていただきたいと思います。
- リカバリー処理(BigQueryからデータを取得して～)
- Cloud Functionsのソース管理及びデプロイ

通常時と比べてリカバリー時のイメージは下記の図のようになります。

f:id:allabout-techblog:20200826165207p:plain — ログ収集基盤のログ転送フロー(リカバリー)

それでは、リカバリー処理から見てまいりましょう！

リカバリー処理

リカバリー処理自体はシンプルで、BigQueryへ格納されているバックアップデータを取得して、通常処理のPubsubへ投げる、だけになります。

BigQueryへバックアップされたデータは通常処理でPubsubが扱うデータと同じフォーマットとなっている
PubsubとDataflowはオートスケールできるため、通常処理にリカバリー処理をかぶせても負荷的な影響はない

実際の処理負荷に対しては気になるところだと思いますが、その詳細につきましてはここでは割愛させていただき、別の機会でご紹介できればと思います。

Cloud Functions設定情報

今回のCloud Functionsの設定情報は下記のようになります。

トリガー : HTTP
ランタイム : Go 1.13

また、内部的にはGCP関連いくつかの環境変数とあわせて、リカバリー用の環境変数も設定してソースの中で参照することにしています。

必要なIAMロール

リカバリーではサービスアカウントを使いますが、そのサービスアカウントに必要なIAMロールは下記になります。各ロールに詳しい方も多いと思いますが、補足として簡単な説明も記載させていただきます。

bigquery.jobs.create : プロジェクト内でジョブ（クエリを含む）を実行する権限。
pubsub.topics.publish : 1つ以上のメッセージをトピックへ追加する権限。
cloudfunctions.functions.setIamPolicy : 未承認のデベロッパーによる該当Functionsへの権限変更を防ぐために、該当Functionsをデプロイするユーザーまたはサービスに与える権限。

ファイル構成

functions.go : メイン処理
go.mod : go言語の依存モジュール管理ファイル

処理の流れ

基本的な処理の流れは下記のようになります。

1.トリガーでCloud Functionsの実行対象関数が呼び出される
2.BigQueryからデータを取得し、Iteratorを回してPubsubへメッセージを送る関数へデータを渡す
3.Pubsubへメッセージを送る

ソース

バックアップデータからログの再収集を行うソースを全部載せると記事が長くなりますので、流れが把握できる範囲で紹介させていただきます(エラー処理もすべて省きます)。

functions.go

package p

import (
    ~省略~
    "cloud.google.com/go/bigquery"
    "cloud.google.com/go/pubsub"
    "google.golang.org/api/iterator"
)

// ①Cloud Functionsでエンドポイントとして使われる関数
func EndPoint(w http.ResponseWriter, r *http.Request) {
    // BigQueryからデータを取得し、1行ずつPubsubへメッセージを送る
    fetchBigQueryData()
}

// ②BigQueryからデータを取得し、Iteratorを回してPubsubへメッセージを送る関数へデータを渡す
func fetchBigQueryData() {
    ctx := context.Background()

    client, err := bigquery.NewClient(ctx, {GCP_ID})
    defer client.Close()

    // バックアップデータ取得用クエリ設定
    q := client.Query({SQL})

    // 実行のためのqueryをサービスに送信してIteratorを通じて結果を返す
    // itはIterator
    it, err := q.Read(ctx)

    for {
        var tc {BQTableColumns 構造体}

        // 引数に与えたtcにnextを格納する
        // Iteratorを返す
        // これ以上結果が存在しない場合には、iterator.Doneを返す
        // iterator.Doneが返ってきたら、forを抜ける
        err := it.Next(&tc)
        if err == iterator.Done {
            break
        }

        // pubsubへメッセージを送る
        sendPubsubMessage(&tc)
    }
}

// ③pubsubへメッセージを送る
func sendPubsubMessage(tc *{BQTableColumns 構造体}) {
    msg := &pubsub.Message{
        Data: tc.Message,
    }

    ctx := context.Background()
    if _, err := {Pubsubのtopicインスタンス}.Publish(ctx, msg).Get(ctx); err != nil {
        return
    }
}

go.mod

module DOMAIN/MODULE_NAME

go 1.13

require (
    cloud.google.com/go/bigquery v1.10.0
    cloud.google.com/go/pubsub v1.6.1
    google.golang.org/api v0.30.0
)

Cloud Functionsのソース管理及びデプロイ

Cloud Functionsはサーバーリソースを各自が管理しなくても良いメリットがあります。
その代わりにというのも不適切かもしれませんが、CloudFunctions上で動かせるソースの管理をどうするか、また、デプロイはどうするかを検討しないといけません。
自分にとっては初のCloudFunctionsだったので、一旦検証時に利用したソース管理とデプロイ手順を紹介させていただきます。

Cloud Functionsへのソース反映方法

Cloud Functionsへのソース反映はCloud FunctionsのウェブUIからも確認できるように、下記の4種類があります。

Inline Editor
ZIP Upload
ZIP from Cloud Storage
Cloud Source repository

Inline Editorの場合はウェブUIから直接ファイルを更新するパターンなので、ソース管理ができない問題があります。
ZIPを利用する方法も、ソース管理ツールからファイルをダウンロードして、ZIP圧縮して、等の遠回りをすればある程度のソース管理はできますが、手間が増えるし、ミスも増える可能性があります。
Cloud Source repositoryはGCP上でのソース管理サービスです。このサービスにはなんと！他のソース管理ツールへのミラーリング機能があったので、今回はCloud Source repositoryを使ってみることにしました。
※現時点でミラーリングできるのは「GitHub」と「Bitbucket」の2種類のみですので他のソース管理ツールをご利用中の場合にはご注意ください。

ミラーリング設定

弊社ではBitbucketを使ってソース管理を行っているので、下記公式サイトの説明に従ってリポジトリのミラーリング設定を行いました。
Bitbucket リポジトリのミラーリング

デプロイ

まずは、Bitbucketの該当リポジトリへ今回のソースをcommitしました。
そのあと、Cloud Source repositoryの該当リポジトリでミラーリングが正常にできたことを確認したので、gcloudコマンドを使ってCloudFunctionsへデプロイを試してみました。

gcloudコマンドを使ってのデプロイは下記公式ドキュメントに詳細が載っているので参考しながらコマンドを書きました。

ソースコントロールからのデプロイ

gcloud functions deploy CLOUD_FUNCTION_NAME \
  --region REGION_ID \
  --source https://source.developers.google.com/projects/PROJECT_ID/repos/REPOSITORY_ID/moveable-aliases/master/paths/SOURCE \
  --runtime go113 \
  --service-account=SERVICE_ACCOUNT@appspot.gserviceaccount.com \
  --trigger-http \
  --set-env-vars HOGEHOHE=AAA,FUGAFUGA=BBB… \
  --entry_point ENTRY_POINT \

基本的には公式ドキュメントに従って書けば問題なくデプロイできることを確認しました。
また、「--runtime」オプションは該当Functionを最初に作るときに指定すれば良くて、そのあとからは該当オプションをしないことで同じFunctionへの更新になります。

おわりに

Cloud Runと比べてCloud Functionsはコンテナイメージのメンテナンスが不要というメリットがあります。
通常のログ収集処理はCloud Runで行うことにしましたが、めったに発生しないであろうログの再収集処理はCloud Functionsで行うことで、メンテナンスコストが節約できると思います。
また、今回は「HTTPトリガー」を試してみましたが、Cloud Functionsには「HTTPトリガー」以外にも「Cloud Pub/Subトリガー」や「Cloud Storageトリガー」もあるので、今後それらも試してみたいと思います。
デプロイについても、今回はgcloudコマンドでの手動デプロイを試してみましたが、近いうちにCircleCIからの完全自動デプロイも試してみたいと思ってます。

今後ともよろしくお願いいたします。

参考サイト

公式サイト

ブログ等

GoでBigQueryクライアントを実装してBigQueryからデータを取得する

2020-06-30

Cloud RunからCloud SQLやMemorystoreへの繋ぎ方

こんにちは！@y_hideshi です。

今回はCloud RunからCloud SQLやMemorystoreにつなぐ方法について紹介します。

Cloud SQLへの接続方法
Memorystoreへの接続方法

Cloud SQLへの接続方法

検証のため、phpMyAdminからCloud SQLにつなぐシンプルな構成のシステムを作ります。

f:id:allabout-techblog:20200629200338p:plain — Cloud Run - Cloud SQL

2020-05-29

データ活用を推進しようとしているお話

はじめに

初めまして、オールアバウトの @akidukin(@Akidukin14) です。この度上手く出来たら noteで公開しようと思っていた内容を「自社のtechblogで書いてよー」と~~低めに脅された~~依頼されたので、気持ちよく執筆させていただくことにしました。

初めてTechBlogを執筆させていただきますので、簡単に私がどんな業務を担当しているのかを説明させて下さい。

興味が無い人は ## 何をしようとしているのかの説明 に飛んでください。(データサイエンティストとして仕事している人なんだなーって認識を持っていただけたら十分です。)

人 : @akidukin14 https://twitter.com/Akidukin14
出身 : 福岡
現所属 : 株式会社オールアバウト開発部マーケティング開発データサイエンティスト

主な業務 :
【ちょっと前まで】

広告配信に利用している機械学習の改善
営業向け資料の拡充
広告配信のレポーティングの拡充 ... 等

【現在】

株式会社オールアバウト全体にデータ活用やっていきましょうよーと話しまわっている(非公認)
出てきた活用案をプロジェクト化して
- PMしたり
- 分析で実際に手を動かしたり
- ダッシュボード作ってみたり
- 機械学習のPoC回してみたり
- 一般で利用できるようにツール化したり ... 等

今回は【現在】主に対応している物についてご紹介しようと思います。

何をしようとしているのかの説明

タイトルの通り「株式会社オールアバウトの各部署のデータ活用を推進しよう」としています。

きっとこの記事を読んで頂いている方は
「会社としてデータ活用を推進していく共通意思があって進めているんだ...!!」
と思われるかもしれませんが、凄く雑に言うと個人的に ~~暇だから~~ やってみたいので進めています。

オールアバウトグループという単位でどんなサービスを運営しているかを簡単に説明します。

株式会社オールアバウト : メディア運営 / タイアップ広告配信の運営
株式会社オールアバウトライフマーケティング : ECサイト運営
株式会社オールアバウトナビ : SNSを利用したエンタメ事業の運営
日テレライフマーケティング株式会社 : ECとTV放送を連動させた事業の運営
株式会社オールアバウトライフワークス : 講師育成や教室運営サービスの運営

様々なサービスの運営をしており、データアナリストやデータサイエンティストといったデータを触る方々からすると垂涎物な環境なのかなーって思います。
(違う業種違う情報のデータが比較的豊富に取得できる点が)

今回、データ活用を推進しようとしているのはメディア運営 / タイアップ広告配信運営の事業領域になります。

※...データ活用 : データソースの整理や掃除、から、実際にデータ分析 ~ 機能の提供を対象のイメージとしております。

現在のデータ活用フェーズについて

そもそも、現在株式会社オールアバウトではデータの活用が全く進んでいないのかというと、そういうわけではありません。
メディア運営に於いてはGoogle Analyticsが社内にかなり浸透し各自でDataportal等を使っていたり、タイアップ広告配信ではTreasureDataにデータがたまっており、タイアップごとの効果測定等にもデータを利用してたりします。
ECサイトを運営しているオールアバウトライフマーケティングではRe:dashを利用して定常的に数値を追う環境もあったりします。

しかし、データの活用度合いが個人の知見に任せされていたり、情報の共有があまりされていなかったり、形骸的にデータを見るだけになっていたりしていました。
いくつかの業務の中では定量的ではなく定性的な判断をすることが常になっている業務、人の知見を元に判断をしている業務等がある。。。
というのが現在の株式会社オールアバウトのデータ活用のフェーズになります。
イメージは伝わりますかね...??

現在のフェーズにおいて、実際に作業にあたっている方やその上司の方々は大なり小なり課題感は抱えており、今までその部分に介入する+出来る人的リソースが無かったというのが背景になります。

「あれ??これデータ活用進めたら、強力に売り上げ貢献とか利益貢献出来るんじゃね??」

f:id:allabout-techblog:20200528104258p:plain — イメージ

どう進めているのか

実際にどのようにデータ活用を推進しているのかという点について、説明させてください。
プロジェクトが動き始めたのが4月からでした。

基本的には

各グループの上長や担当者にデータを利用してやってみたい事をヒアリング
データ環境の情報整理
優先順位付け、プロジェクト化
分析案や仮説のブレスト
タスク化
分析作業及び報告

という流れで進めています。

元々各GMや担当者はデータに対しての理解度が高かったのですが、データを使って何が出来るか分からないという壁がありました。

そこで、テーマを「ドラえもん」に設定し、「あんなこっと良いな、出来たら良いな、不思議なデータで叶えてあっげっるー」という理想ドリブンでそれぞれやってみたい事をヒアリングしていきました。
この時、ooを解決したい!!みたいな形ではなく、ooがxxみたいになればいいのになー。という形でふんわりした内容を上げてもらって、それを詳細に詰めていくという導入から始めました。

やりたい事いっぱい出た。
中には「知見に基づいてやっている作業の自動化が出来たら凄く嬉しい。」等も出てきて狙い通りでした。

そして、出てきたものに対して、優先順位をつけ PO(プロジェクトオーナー) を付け、プロジェクト化を行いました。

その後、どういった分析をすれば実現できるのか、や、どういったデータを見れば示唆が出そうなのかのブレストを行い、タスクへ落とし込み、分析の作業に移ります。

データ活用するにあたって、壁になる事の一つに担当者と作業者間の期待値コントロールがあると思います。
正直最初は「理想ドリブンでプロジェクト立ち上げちゃったけど、期待値コントロールどうしよう...」と悩んでいました。
期待値が凄く実現性と離れた時は、ミーティング外での啓蒙活動やミーティング自体の開催頻度を上げて細かくOUTPUTを出しつつ期待値や結果を下げていく方向へ持っていこうと考えてたりしました。
が、そんな心配が具現することなく、思ってたより大丈夫だった(今後出て来るかもしれませんが...)

こうしたい未来のお話

まだ走り出したばかりで100年後も変わらず、こう思っているかと言われると自信は無いですが、、、

将来的にはグループ会社全体でデータ活用なら @akidukin (または付随するその組織)に相談してみよう、となるのが理想です。
後はニーズをくみ取りながら、効果的な機能の提供を自発的に出来るようになるともっと嬉しい。企画 ~ 提供を一手に担える

受けた相談を元に実際にデータを見てみたり、分析してみたり、結果を元に改善案や何かしらの機能提供まで出来るようになったら良いです。みんな幸せHappy

上記のような理想に対してはまだまだ溝があり(始めたばかりなので当たり前ですが)、その溝を埋めるためにこんなロードマップを考えています。

こちらからデータ活用についてのニーズのヒアリングを行い、プロジェクト化 <- イマココ
プロジェクトに対して対応、及び改善案の提案や実施
良いor悪い影響の社内共有
メディア運営 / タイアップ広告配信運営以外の事業領域へデータ活用についてのニーズのヒアリング、プロジェクト化
プロジェクトに対して対応、及び改善案の提案や実施
良いor悪い影響の社内共有
... ぐーるぐる回す
ニーズの策定 + 企画立案 + 企画試行

まずはご用聞き -> 誠実に対応 -> 正しく結果を共有のサイクルを繰り返してデータを使う事の効果を知ってもらう (と同時にそれぞれの事業部で何をしているのかをより深く知る) その後、生まれそうなニーズや生まれたニーズを元に改善できそうな部分を考えていく。という大まかな流れになるかなーと妄想しています。

きっとその間で、

一緒に分析を進めてくれる人達のレベルアップとか
一緒に実装を進めてくれる人達のレベルアップとか
どうやって膨大になっていくプロジェクトを適宜割り振っていくかとか
そうなるともっと人が必要になるよなーとか
分析するマシンリソースがひっ迫してくるだろうから対応考えないと行けないよなーとか
複雑になっていくデータリレーションをどう管理していけばいいのかなーとか
etc...

多分今考えている 5倍ぐらいは出て来るとは思いますが、来る未来を想像しながらとりあえず目先の事を頑張る。

終わりに

改めて書き出してみるとあまり固まっていない事が判明して困惑しています。

今後進めていけるのであれば、より影響範囲は広めていきたいなー、色々なデータを触ってみたいなーとか思っています。が、
グループ会社を横断するって事を考えると、良く分からない大人の事情も出て来るだろうし、、、、
じゃあ提案をして改善していきましょう、ってなったときのステークホルダーとの折衝とか、、、、

まあ未来を悲観してもしょうがないので、今は目先の事をちゃんとこなしていく事にしています。

その辺り、もし同様の経験をされた方がいらっしゃったらお話お聞きしてみたい...

拙い文章でしたが、ここまで読んでいただいてありがとうございました。
随時、経過とか得られた知見とかアウトプットしていきたいなーと思っているので、よろしくお願いします！

2020-04-27

Cloud RunとGCPの他サービスを使って簡単なシステムを作ってみました

こんにちは！オールアバウトの @y_hideshiです。

今回は、昨年GA(General Availability)された Cloud RunとGCPの各種サービスを連携させて簡単なシステムを構築、その際に得られた知見を記事にしたいと思います。

作成したシステム
Cloud Run について
- Cloud Runへのデプロイ
  - Webからのデプロイ
  - gloudコマンドによるデプロイ
- 設定値について
- Cloud Run：まとめ
関連サービスを利用することによるメリット
- Cloud Build
  - GCR、Cloud Runへのデプロイをするための認証をなるべく手軽に済ませたい
  - プロジェクトが変わってもすぐにデプロイしやすいようにしたい
- Cloud Pub/Sub
- Cloud Scheduler
所感

作成したシステム

今回作成したシステムは「GCP確約利用割引の期日を定期的にチェックして、期日の近いものをslackに通知する」というものです。

GCP確約利用割引は1年間または3年間の支払いを確約する代わりに、特定の量のvCPU、メモリ、GPU、ローカルSSDを割引価格で利用できる仕組みです

f:id:allabout-techblog:20200420213645p:plain — 作成したシステム構成

使用したサービス

※ 今回は連携するサービスの詳細については触れませんが、各サービスごとの採用理由やメリットなどを解説して行きたいと思います。

オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

コロナ禍での情シスの対応とそこから見えたもの

はじめに

目次

ドタバタなコロナ対策

情シス業務の変化

変化の中で見えてきたもの

今後の計画

最後に

まとめ

Google Cloud Functionsを使ってバックアップデータからログの再収集を行う方法の紹介

概要

リカバリー処理

Cloud Functions設定情報

必要なIAMロール

ファイル構成

処理の流れ

ソース

Cloud Functionsのソース管理及びデプロイ

Cloud Functionsへのソース反映方法

ミラーリング設定

デプロイ

おわりに

参考サイト

公式サイト

ブログ等

Cloud RunからCloud SQLやMemorystoreへの繋ぎ方

Cloud SQLへの接続方法

データ活用を推進しようとしているお話

はじめに

何をしようとしているのかの説明

現在のデータ活用フェーズについて

どう進めているのか

こうしたい未来のお話

終わりに

Cloud RunとGCPの他サービスを使って簡単なシステムを作ってみました

作成したシステム