ビットの海

ゆるふわソフトウェアエンジニアしゃぜのブログ

Airflow 公式 docker image を使って、Cloud Composer の Local 開発環境を構築

サマリ

  • local で Composer 向けの DAG 開発をしたい
  • BigQuery Operator ぐらいはちゃんとうごいてほしい
  • Airflow 2.1.x
  • Python 3.8
  • ほんとはリポジトリつくってそれ pull してねってすれば親切なんだろうけど面倒くさいので個人のブログに書きなぐっている

ファイル

ディレクトリ構成

.
├── Dockerfile
├── credentials
│   └── credential.json
├── dags
│   └── hello.py
├── docker-compose.yaml
├── .env
├── logs
└── plugins

credential.json

Google Cloud の Service Account のもの

.env

AIRFLOW_UID=503
AIRFLOW_GID=0
GOOGLE_APPLICATION_CREDENTIALS=/opt/airflow/credentials/credential.json
AIRFLOW_CONN_GOOGLE_CLOUD_DEFAULT=google-cloud-platform://?extra__google_cloud_platform__key_path=%2Fopt%2Fairflow%2Fcredentials%2Fcredential.json&extra__google_cloud_platform__project=[your project_id]

docker-compose.yaml

公式のを拾ってくる

curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.1.4/docker-compose.yaml'

変更点

image 変更

image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:2.1.4}

を適当な自分で build する image に

image: docker-airflow-for-gcp

volume 追加

  volumes:
    - ./dags:/opt/airflow/dags
    - ./logs:/opt/airflow/logs
    - ./plugins:/opt/airflow/plugins
    - ./credentials:/opt/airflow/credentials # 追記

credentials の volume を追記

Dockerfile

gcloud コマンドも居てほしいなと思って、cloud sdk install してる

FROM apache/airflow:2.1.4-python3.8

RUN mkdir -p /opt/airflow/credentials

USER root

RUN sudo apt-get update -yqq \
  && sudo apt-get install curl apt-transport-https ca-certificates gnupg procps -yqq

RUN sudo echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

RUN curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

RUN sudo apt-get update \ 
  && sudo apt-get install google-cloud-sdk -y


RUN gcloud version

操作

コンテナビルド

$ docker build --rm -t docker-airflow-for-gcp .

DB初期化

$ docker-compose up airflow-init

起動

$ docker-compose up

さいごに

  • localhost:8080 でブラウザアクセスできるようになる。
  • id/passowrd は 初期状態で airflow / airflow
  • apache-airflow-providers-google とかは、この Airflow 公式イメージには入ってた。他必要なものがあれば、Dockerfile で pip install してあげればよい。
  • これで、BigQuery Operator ぐらいは動くけど、他の物を動かすときは、環境変数(.env)に追加が必要かも。

参考にしました

Cloud Composer の辛さと、それに負けない開発フローの構築 ~ローカル環境開発編~|JDSC|note

coc-python が archive されたので、coc-jedi と coc-diagnostic に乗り換えた

はじめに

元々 coc-python でLSPとして以下のような設定をして使っていたが、coc-python が停止してしまったので、乗り換えたというお話。

coc-settings.json

   
{
  "languageserver": {
    "python": {
      "command": "pyls",
      "filetypes": [
        "python"
      ],
      "trace.server": "verbose",
      "args": [
        "-vv",
        "--log-file",
        "/tmp/foo.log"
      ],
      "settings": {
        "pyls": {
          "trace": {
            "server": "verbose"
          },
          "configurationSources": [
            "flake8"
          ],
          "plugins": {
            "pydocstyle": {
              "enabled": false
            },
            "pycodestyle": {
              "enabled": false
            },
            "yapf": {
              "enabled": false
            },
            "pylint": {
              "enabled": false
            }
          }
        }
      }
    }
  }
}

やりたいこと

  • Language Server によるアシスト
  • Flake8 での Lint
  • Black での Format

どうするか

coc-jedi と coc-diagnostic を使います。

Language Server によるアシストは coc-jedi を使う

coc-jedi の導入

:CocInstall coc-jedi

Language Server は coc-python 時代は、 pip install 'python-language-server[all]' していたのですが、jedi の場合は以下のようになる。

pip install jedi-language-server

python-language-server(pyls) と同じく、vim が参照できる path を jedi-language-server も設定しておく。

そして、coc-settings.json にも設定を書く

  "jedi": {
    "enable": true,
    "startupMessage": false,
    "executable.command": "jedi-language-server"
  }

coc-diagnostic で Lint と Format

インストール

:CocInstall coc-diagnostic
pip install flake8 black

coc-settings.json の設定

  "diagnostic-languageserver.filetypes": {
    "python": ["flake8"]
  },
  "diagnostic-languageserver.formatFiletypes": {
    "python": ["black"]
  },
  "diagnostic-languageserver.linters": {
    "flake8": {
      "command": "flake8",
      "debounce": 100,
      "args": [ "--format=%(row)d,%(col)d,%(code).1s,%(code)s: %(text)s", "-" ],
      "offsetLine": 0,
      "offsetColumn": 0,
      "sourceName": "flake8",
      "formatLines": 1,
      "formatPattern": [
        "(\\d+),(\\d+),([A-Z]),(.*)(\\r|\\n)*$",
        {
          "line": 1,
          "column": 2,
          "security": 3,
          "message": 4
        }
      ],
      "securities": {
        "W": "warning",
        "E": "error",
        "F": "error",
        "C": "error",
        "N": "error"
      }
    }
  },
  "diagnostic-languageserver.formatters": {
    "black": {
      "command": "black",
      "args": ["--quiet", "-"]
    }
  },

フォーマットするばあいは、以下のコマンドを呼び出す

:call CocAction('format')

参考にしています

coc-pythonがArchive入りしていることに気がついたのでcoc-jediに変えてみた | DevelopersIO

Quipper Japan の 思い出

これはなに

Quipper Japanというなくなってしまったが、素晴らしい組織/企業を懐かしむ独り言です。

(インターネット上から Quipper という文字列が消えてきたので、少しでも残したいなと思って書きました)

あなたはなに

リクルートからの出向で、2019年4月〜2021年9月の2年半ほどQuipperに所属したイチ元社員です(すでに退職済)。

最終的にQuipper Japan の事業と人材は2021年9月末にリクルートに吸収されたので、Quipper 最後の2年半所属したということになるかと思います。

(Japanの事業はリクルートに吸収されましたが、フィリピンとインドネシアは新たにQuipperの現地法人が設立されて、事業を継続しています)

Quipper って

web.archive.org

www.recruit.co.jp

渡辺雅之氏(元DeNA創業メンバー)が、2010年に創業した、グローバルをターゲットにした、Edtechプラットフォームを提供する企業が、Quipper でした。

いろいろ端折りますが、2015年にリクルートに買収され、日本の事業については、リクルートスタディサプリ(当初は受験サプリ)とインテグレーションされました。

2019年当時の体制としては、Quipper Japan で、Quipper 社員と、リクルートから出向したメンバーで、スタディサプリの開発をしていました。

当時はフィリピン、インドネシア、メキシコ、日本で主に事業展開していました。

Quipper の素晴らしかった点

良い企業文化

5つの指針として、

  • UserFirst
  • Diversity
  • Ownership
  • Fact-Based
  • Growth

があり、どれも日常的に意識され、組織運営されていたと思います。

こういったスローガンが日々の業務にきちんと落ちているのが素晴らしいと感じました。

あと、言語化が難しいのですが、ファウンダーの方々の思い(世界の果てまで、最高のまなびを届けよう)を感じることができる環境でした。

良い開発組織

入社して最初に感銘を受けたのが、開発環境です。

blog.studysapuri.jp

いろいろSRE中心に整備されていたのですが、Monorepo で Pull-Request を作成すると、pr-xxx という k8s の namespace が作成され、各マイクロサービスが立ち上がった状態で、テスト環境が生成されるのには非常に感銘を受けました。

codezine.jp

開発組織の力が一番顕在化したのが、上記のコロナ対応だったと思います(自分はjoinした直後でほぼ貢献してませんが...)。

また、Slack / GitHub / Google の User Nameを統一することで、リモート時代でも大変仕事がしやすかったことを記憶しています(github-management という社内の仕組みがありました)。

社内の仕組みだけではなく、開発に必要な SaaS プロダクトも一通り使うことができたのも便利でした。

おまえは何をやっていたのか

会社のブログに書いた話でいうとこのへんですかね

Cloud Dataflow で実現する柔軟なデータパイプライン - スタディサプリ Product Team Blog

Cloud Composer(Airflow)で分析者向けBigQuery SQL実行基盤をつくりました - スタディサプリ Product Team Blog

Quipper/スタディサプリの素晴らしい人々と仕事ができたことは自分の財産になっています。

さいごに

Quipper ありがとう!

Mac で しゅっと Embulk をセットアップする (2022年5月版)

知らないうちに adoptopenjdk はなくなっているのであった...

$ brew tap homebrew/cask-versions
$ brew install --cask temurin8

$ export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
$ java -version

$ export EMBULK_VERSION="0.9.24"
$ curl --create-dirs -o ~/.embulk/bin/embulk -L "https://github.com/embulk/embulk/releases/download/v${EMBULK_VERSION}/embulk-${EMBULK_VERSION}.jar"
$ chmod +x ~/.embulk/bin/embulk

$ ~/.embulk/bin/embulk --version

2021年の振り返り

もう4月で今更なのでこっそりと

仕事

なんやかんやあった

プライベート

いろいろあって疲れた...

書いたもの

Qiita

会社のブログ

Hackしないふつーの育児

adventar.org

この記事は 子育てエンジニア Advent Calendar 2021 の13日めです。

以前書いたものはこちら

子育てソフトウェアエンジニアの継続的な学び方のエッセンス - ビットの海

子育てソフトウェアエンジニアのワークとライフ - ビットの海

こんちには、2児の父です。

子育てエンジニア Advent Calendar なので、小粋な子育てHackの話でも書きたかったのですが、先日の家庭内重大インシデントで疲弊してしまってそういう気分にはなれず、今年は掲題のような「Hackしないふつーの育児」にします。

重大インシデント

端的にいうと、上の子の感染症ブドウ球菌性熱傷様皮膚症候群)による入院です。

入院13日目にして、やっと退院することができました。当人は元気になったので、それは良かったのですが、共働きの親は疲労コンパイルです。

Hackしないふつーの育児

知育的なものだったり、時間の効率的なマネジメントであったり、育児Hackは多くあり、私もそういう話好きなんですけど、今回の入院を通して改めて考えたのはふつーの育児です。

必要最低限の育児、と言い換えても良いかもしれません。

育児のフリーペーパーかなにかで、インタビューに答えている人が言っていたのをぼんやり覚えているんですが、育児で大切な(必要最低限)のことって、「衣食住を整える」だと言っていて、いま非常に共感しています。

特にうちのような未就学児を抱える家庭が、それは一番に意識しないといけないこと(それ以外はある意味 Optional である)と言っても良いのではないでしょうか。

育児の衣食住

衣は、季節に合わせて、清潔で安全なものを用意しないといけないし。

食は、これも季節に合わせて、広く栄養を考えたものを用意しないといけないし。

住は、安全性に気をつけて、遊びができる環境を用意してあげないといけないですよね。

情報に踊らされがちな我ら

ともすれば、知育的な話題なんかにどうしても関心が行きがちです。

が、子供が入院というインシデントを経験して感じたのは、睡眠時間をちゃんと確保するとか、手洗いがちゃんとできているとか、衣食住がちゃんとしているか、テレビ見すぎないとか、絵本読み聞かせできてるか、etc..

基本的なところを時々見直して、そういうところを大事にしたほうが良いんじゃないかな〜という感覚でした。

こういう基本的なことが出てきてたら、自分たちの育児を自己肯定していって良いと思います!!!

私育児ちゃんとできてる!!!(自己肯定マシマシ)

(きっと来年はぜんぜん別のことを書いてると思います)

エンジニアが起案を通すためのIT投資評価の話

はじめに

いちエンジニアといえども、時には何かしらの起案を自組織や上司に対して行うことがあると思います。

片手間でできるような仕事であれば、起案もへったくれも無いかもしれませんが、ン千万のお買い物なんかは、だいたいの組織では、それなりの説明が必要だと思います。

ちなみに、私が何かを起案する、という行為を初めて意識したのは、ン年前の新卒の頃、先輩が、社内に検証用の環境を作るために各種利害関係者の説得をしていたのを横から眺めていたときでした。

さて、今回の話は、以下の本に書いていることと自分の経験をかいつまんでいます。興味のある方は本を読んでいただくと良さそうです。

いざ起案のための資料をつくろうとすると...

起案のための資料をいざ作ろうとすると根本的な問いが発生すると思います。

「なぜその支出が必要なのか」です。

それは、小さい会社であれば社長さんかもしれませんし、大きな会社であれば、多くの役職者に問われることかもしれません。

これが、例えば ECサイトにレコメンドシステムを追加して、売上を10%上げたいんです!分析結果から目処が立っています!」と言えると大変楽な話ですね。

ひねくれた人以外は反対しなさそうです(投資金額次第かもしれませんが)。

ただ、すべての支出がそういうわかりやすいものばかりではありません。

「開発に便利な SaaS を導入したい(が使うのは一部の人間だけだな)」かもしれませんし、「壊れそうで壊れないサーバをいい加減新しいのにしたい(が保守が残っている)」のようなものかもしれません。

こういった場合、利害関係者(主にお財布の紐を握っている人)がその必要性を両手をあげて賛成してくれることは、概ね稀であり、支出の為に説明なり、説得が発生すると思います。特に金額が大きくなればなるほど...ですね。

そういったとき、各々の経験から、「これを導入しないと若手が辞めますよ」とか、「このサーバー新しくしないと落ちた時にoo部から怒られますよ」みたいな言い方をするかもしれません。

それはそれでありなのですが、「ITに関して支出が伴うものはすべからくIT投資であり、そのIT投資の評価手法はいろいろある」ということを知っていると、資料を作ったり、人を説得したりする際の道具が増えることになり大変便利なので、いくつか紹介します。

IT投資の分類

まず、IT投資を大まかに分類してみます。

これは、「使っているデータベースの保守が切れたので更新する」みたいな投資と、「ECサイトの売上げアップの為に外部にコンサルタントを依頼したい」のような投資とでは、同じIT投資といっても性質がかなり異なるからです。

性質が異なるものを同列に扱うことは困難を極めます。

といっても、制度的、法的にスタンダードな分類があるわけではなく、実際は企業単位で何かしらの分類がされていることだと思います。

シンプルであれば

  • 攻めの投資
  • 守りの投資

もう少し分けて、上述書籍(図解即戦力 IT投資の評価手法と効果がこれ1冊でしっかりわかる教科書)から引っ張ってくると...

  • インフラ型
    • 複数のアプリケーションのための共通基盤に対する投資、など
  • 業務効率型
    • 省力化をすすめるための投資、など
  • 戦略型
    • 顧客拡大のための企業戦略に基づく投資、など

所属企業に分類の定義がなければ、こういうのをとりあえず定義してみるのも良いかもしれません。

IT投資の評価手法

さて、やっと本題のIT投資の評価手法に入りたいと思います。

IT投資評価の難しい点は、いくつかありますが、制度的、法的に確立しした手法があまりないというが個人的には大きいと思っています。

例えば、エンジニア界隈で有名な「技術的負債」という例えがありますが、多くの経理担当者に理解される概念には至って居ないと思います。

とはいえ、現実は何かの手法がなければ困ってしまうので、いろんな人が知恵を出して考えたものがあります。

手法は、大きく分けて、財務的手法、非財務的手法に分かれると思います。

財務的指標は何らかの財務的な数字(売上とか利益とか)で、測れるもの。非財務的指標は、財務的指標以外のもので効果を測るものです(アンケートによるユーザ満足度、とか)。

さて、以下は上述書籍(図解即戦力 IT投資の評価手法と効果がこれ1冊でしっかりわかる教科書)に記載されている手法です。

手法 評価手法 内容
財務的手法 ROI(投資利益率/投資回収率) 投資額に対する回収額(利益)の割合
  回収期間法 投資額をどれくらい早く回収できるか
  NPV法(正味現在価値法) 割引キャッシュフローの総和
  IRR法(内部収益率法) NPVが0になるときの割引率
  ABC/ABM 業務コストの削減量
非財務的手法 妥当性評価 世間相場、同業他社のベンチマークなど
  ユーザー満足度評価 利用者のアンケート調査結果など
  SLA(サービスレベル合意) システムのサービス水準
  情報セキュリティ投資評価 リスクの大きさ
  IT-BSC CSF、KPIの達成度

もちろん、これがすべてではありません。他に財務的、非財務的手法はたくさんあります。また、コンサルティング会社などは独自の非財務的手法で評価することも多いようです。

ここの手法について説明するのは手に余るので、それぞれの書籍等を読んで欲しいのですが、ここで伝えたいのは

  • 財務的手法、非財務的手法はざまざまある(著名なROIだけ、ではない)
  • 特に非財務的手法は、ある意味利害関係者と合意できる手法であれば何でもありの世界である
    • 「このソフトウェアを導入しないと、中途採用ができないのだ」みたいな手法の合意もありえる
  • 現実の起案では、複数の手法、ないし、簡易的な手法で、その起案にメリットが大きいことを説明する、ということ
    • この施策によって、このKPIに効きそうだからやりましょう(雑な IT-BSC )ぐらいのラフな合意で物事が進むことも多いかと

です。

そして、先程のIT投資の分類と関わってくるのですが、IT投資の分類と評価手法は相性があります

例えば、「新しいセキュリティソフトウェアを導入したい」という起案でROIを語ることは現実には難しいケースが多いかと思います。目的が、新しい脅威に対応する、ものであり、なにかそれが直接的な利益や売上につながるものでは無いからです。

その場合、何かしらの非財務的評価を用いることになると思います。

この、IT投資の分類と評価手法を適切に組み合わせることが、起案に対する納得を得る為に必要だと思います。

さいごに

IT投資評価の話になると、ROI の話にどうしてもなりがちだと思います。

経営者は財務的な数字で物事を判断しているため、そのプロトコルに合わせようとすると、どうしても ROI の文脈で語りたくなります。

他方、IT投資は、利益や売上につながらないものの、事業の安定した継続性(セキュリティに対する投資などはそうでしょう)のための投資も多くあります。

現実には、個人の信頼から投資が通ることも多く、ooさんが言うなら大規模リファクタリングやりましょう、みたいな話も多いかと思います。それで成立するのであれば、それでも良いのかもしれません。

「技術的負債」のような概念が通じる組織であれば、それでも良いと思います。

自分は、アリストテレスの説得の三原則の話が好きで、説得には「エトス」「パトス」「ロゴス」が必要だとされています。

ロジカルに資料を作ったり、投資評価の計算をしたりするのは、エトス。

個人の信頼に基づいて動いてもらうのは、ロゴス。

そして、最終的には、実現したいというパッション(熱量)がなければ困難な問題ほど前に動かないと考えおり、自分がその対象に対してどれだけ真剣なのか、パトスを持って伝えるのが大事なのでは、と考えています。

加えて言うなら、提案を受ける側の態度もとても大切で、「エトス」「パトス」「ロゴス」を含む提案をきちんと(通す通さないは別として)受け止めるのが、良い組織なのでは?と思います。