BigQuery に入門したのでハマったことをメモする

はじめに

最近社で BigQuery にクエリ投げて結果を取得して、その結果をごにょごにょするというのをやり始めて BigQuery に入門したのだけれどそりゃそうですよねということでハマったのでメモとして残しておく。

基本的な処理

使うのは Ruby と google-cloud-bigquery です。
README にも載ってますが基本的には下記のような感じで書きます。

$ gem install google-cloud-bigquery
$ irb
require "google/cloud/bigquery"

bigquery = Google::Cloud::Bigquery.new(
        project_id: "hogehoge",
        credentials: gcp_credential_path
      )

data = dataset.query "SELECT * FROM table"

data.each do |row|
  puts row[:hoge]
end

table が既に存在していればこんな感じで情報が取得できるわけですよ。

取得する件数が多い場合

今回ハマったのがこのパターンです。クエリで取得する件数が多い(100000件以上の)場合実は上記の方法では 100000 件しか取得できないのであった...
Treasure Data の workflow の結果取得する際は気にしなくてよかったのでハマったが limit かかるのは当然と言えば当然ですね...

data = dataset.query "SELECT * FROM table LIMIT 1000000"

data.count
=> 100000

table に 100000 件以上のデータがあった場合上記のような結果になってしまいます。
なのでお手軽に全件取りたい場合は下記のようにする必要があります

data = dataset.query "SELECT * FROM table LIMIT 1000000"

begin
 puts data.count
end until (data = data.next).nil?

Google:: Cloud:: Bigquery::Job を使う場合は下記のような感じ

dataset = bigquery.dataset("dataset_name")
job = dataset.query_job "SELECT * FROM table LIMIT 1000000"
job.wait_until_done!

data = job.data
begin
 puts data.count
end until (data = data.next).nil?

さいごに

BigQuery なんか色々便利そうなのでちゃんと情報収集しなければ...となっている

Github Projects を使ってドラッカー風エクササイズをやった

はじめに

ドラッカー風エクササイズとは

ドラッカー風エクササイズとはというのは社のけんちゃんくんさんが書いてある下記の記事を参照してください

tech.pepabo.com

やるとなった経緯

僕が社に入社した直後のチームでドラッカー風エクササイズが開催され、入社したばかりの自分が周りに何を期待されているのか？や自分の強みはこれですというのを発表できる場があったのはとても良い機会だったという記憶があり、CTL を勤めている minne 事業部では今年から少しチーム体制の変更があったのでこれを機にやるかとなったのでした。

Github Projects を使った経緯

過去の経験からいくつか本質ではないところに気をつける必要があったという記憶がありそこを何とかしたいという思いがありました。

それが下記のようなものです。

• (自身が)字が汚いので付箋に文字を丁寧に書くということに意識と時間を取られる
• 記入後は付箋を見て物事が進んでいくのだが、付箋では小さくみんなで見づらい
• 終わった後に振り返るには写真を撮るや付箋を保存するなどがあり振り返りづらい

これらがあったのですが、これまたけんちゃんくんさんに社のデザイナーが notion を使ってやってたというのを教えてもらいました。

それがこちら

speakerdeck.com

この資料を読んでたら notion でやることで先に挙げた懸念が解消されるし良いなとなったのですが、 notion のアカウントそもそも全員持ってないかもな？というのがあり閃いたのが Github Projects を使うという方法です。

Github Projects を選んだ理由は下記のようなものです。

• 社では GitHub Enterprise を採用しており、全社員アカウントを持っている
• 社の情報のほとんどが GitHub Enterprise 上に集まっている
• 先で挙げた懸念も全て解消される

やり方

ここからは実際のやり方の説明です。

1. Project 作成

こんな感じで入力して作成

2. 参加者に自身の名前で column を作成してもらう

3. 自身に関しての質問を記述する

4. 検索窓に author:自身のアカウント でフィルターをかける

これによって誰のカラムに記入したか把握しやすくなる

5. 他人に関しての質問を記述する

これ以降は基本的には最初にあげた社のテックブログの内容と同じに進んでいきます。
今回は終わった後の感想も各位の column に書いてもらいました。

さいごに

Github Projects を使用することでより本質に意識を割くことが可能になったと感じます。

また、いつでも普段使っているリポジトリを見直せば振り返ることが可能になっているというのも便利ポイントかと思いました。

Kubernetes Meetup Tokyo #24 で登壇してきた #k8sjp

Kubernetes Meetup Tokyo とは

k8sjp.connpass.com

Kubernetesのことを詳しく聞く会とのこと

登壇経緯は青山さん(以下青)

青「次回○○って回なんですけどネタないですか？」
僕「〜って感じなら喋れますよ」
青「ではそれで」

雑にまとめるとこんな感じ

登壇内容

speakerdeck.com

minne の開発環境が kubernetes 導入したらこんな感じに変わりましたよって感じで、
導入以前に感じていた課題は解決したけど新しい課題が出てきたよという内容

twitter 眺めてると紹介したツール知らんかったというのもちらほら見かけたので、よかったかなと(普通にみんな知ってるんでは？意味あるのか？と不安になってた)

質問もいくつかもらったのと懇親会でも色々お話できたのでよかった.

資料内で紹介している telepresence に関しては下記の記事を参照してください
shiro-16.hatenablog.com

その他の内容

体調が無だったのでほぼ記憶がアレなのですが、カーネルの話があったりエフェメラルコンテナの話があったり(資料はインターネットを探してください...)

Rails Developers Beer Bash 〜Railsのトレンドとこれから〜 で登壇してきた #railsbeerbash

Rails Developers Beer Bash 〜Railsのトレンドとこれから〜 とは

techplay.jp

Rails6 についてどうのこうの喋る会(雑)

登壇経緯などは資料に書いてあるので読んでください

登壇内容

Beer Bash ということもあり、登壇者の人々で乾杯前に練習と称して先に飲んでいたのでちょい酔いという状態で登壇した。

speakerdeck.com

Rails6 にする為に TA をしたって話

結局リリース自体は出来なかったので TA は失敗だったのだけれど、あとはリリースのみなのでまぁほぼ成功では？

その他の内容

Rails 6 Multi-DB 実戦投入 from kiyots

www.slideshare.net

Rails6 で対応された multi db の話

minne でも switch_point を使用して multi db 対応してるので Rails 標準で対応されるのは嬉しいですね。
Rails6 upgrade 後に switch_point から標準に移行すると思うのでその時に参考になりそうな資料でした。

パネルディスカッション

登壇だけという話だったのですが、急遽前日にパネルディスカッションも出てくれんか？と言われて出ることになった。
事前に頂いていた質問のほとんどが既に出来上がっている資料に書いてあり...これ登壇時にほぼ話すんじゃが...みたいな気持ちになって不安だったが、流石モデレーターのうなすけという感じでなんかいい感じになった気がする

minne のマイクロサービス化の話(たぶん過去にこのブログでも触れた)とか並列 test が標準機能になって嬉しいとか gem の update 戦略とか話した記憶(途中からすごくトイレ行きたくなったのだけは鮮明に覚えている)

自分以外のパネラーの人々の所属する社での方針やお悩みなども聞けてよかった。

懇親会 & LT大会

LT の資料は割愛(探すのがめんどくさかったとかそういうんじゃないんだ...)
それな〜とあるあるな感じの内容が多かったような。

懇親会もなんかずっと喋っていた気はする。

• 手動テストする際の範囲の話
• dependabot と GHE の話
• 管理画面の gem の更新の話

とか他にも色々話した記憶

最後に

最近クラウドネイティブ関連の事ばかりやっていて Ruby/Rails 関連の勉強会も凄く久しぶりだった気がするんですが、こっちの方が知ってる人が多いので安心するというのはあるなという気持ちになって不思議な感じ

他社の人々と Rails 関連の話をがっつり出来たのも久しぶりだったのでとても有意義な時間を過ごせました。
ありがとうございました。

EKS で Auto Scale 導入したお話

はじめに

お仕事で開発している minne というサービスは OpenStack と AWS のハイブリットクラウドなのだけれど(詳細はこちら)色々つらみがあってそのつらみを解決するために Kubernetes への移行を行ったんですよ。(移行についてはまた別のお話なので何処かで)

ハイブリットなのは変わらず OpenStack に cluster 構築してというのと AWS 側は EKS を使うという構成。

それで EKS 側は Auto Scale 使えるじゃん！ということを思い出したので実際に導入したという話。

Auto Scale 導入までの道のり

Auto Scale を導入するまでに必要な手順がいくつかあるので順を追って解説

Metrics Server の導入

docs.aws.amazon.com

だいたい手順は上記に書いてあるんですけど このリポジトリ clone して version とかきになるなら選んで apply すれば良いという感じ

$ git clone git@github.com:kubernetes-incubator/metrics-server.git
$ cd metrics-server

# このままだと最新の master なので最新のリリース version に切り替えるとかやる

$ kubectl apply -f deploy/1.8+/ # Kubernetes の version によって 1.8+ じゃなくて 1.7 とかのディレクトリを選ぶ必要がありそう

$ kubectl get deployment metrics-server -n kube-system --watch
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1         1         1            1           10d

$ kubectl top node
NAME                                              CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        15%       xxxxMi          60%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxm         3%        xxxxMi          54%
ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal   xxxxm        24%       xxxxMi         65%

これで node や pod の metrics を確認できるようになるので Horizontal Pod Autoscaler を使うことができるようになる。

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler - Kubernetes

Horizontal Pod Autoscaler(以下 HPA) は雑にいうと負荷によって pod 数を増減(スケールイン/アウト)させるやーつ

下記のような yaml を用意する。

# hpa.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: sample-hpa
spec:
  minReplicas: 2 # 最小の pod 数
  maxReplicas: 200 # 最大の pod 数
  metrics:
  - resource:
      name: cpu # pod の cpu の使用率を基準に増減させる
      targetAverageUtilization: 20 # 使用率 20% を基準に増減させる
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-deployment # 増減させたい deployment の名前を指定

$ kubectl apply -f hpa.yaml
$ k describe hpa
Name:                                                  sample-hpa
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration=.....
CreationTimestamp:                                     Fri, 19 Jul 2019 12:03:05 +0900
Reference:                                             Deployment/sample-deployment
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  15% (xxxxm) / 20%
Min replicas:                                          2
Max replicas:                                          200
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     False   BackoffBoth         the time since the previous scale is still within both the downscale and upscale forbidden windows
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  33s   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

これで HPA が有効になった。

最初は Metrics の current 部分が unknown となるが待っていれば Metrics 収集して正常になるはず。

注意が必要なのは対象の deployment の全 container の resources (今回は cpu が対象なので cpu)が設定されていないと unknown のままで Events にエラーが出てるはず。他にも対象の deployment と同じ label 名の deployment の各 container も同様に resources が設定されてないといけない > see

HPA が有効になったので pod が増減するか見てみる

# アクセス数とかは調整してください
$ ab -n 100000 -c 100 "対象の deployment へアクセスが流れる IP を指定"

# 別プロセスで
$ kubectl get pods --watch

これで pod が増えたり減ったりする様子が眺められるはず。
k describe hpa で hpa の様子を見ると Events に pod を増減させている情報も表示されます。

これで HPA の導入は終わり

Cluster Autoscaler

GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

最後に workernode を増減していきます。

まずは workernode の IAM に Auto Scale 周りのアクセス権を付与する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

上記のポリシーを作成し workernode のロールにアタッチする。

Autoscaler のマニフェストは こちら

YOUR CLUSTER NAME の箇所を自身の環境に合わせて apply

pod の増減で確認した時のように負荷をかけつつ下記で log を眺める

$ kubectl logs -f deployment/cluster-autoscaler -n kube-system

# 別プロセスで
$ k get node --watch

これで EKS での Auto Scale の導入はおしまい

さいごに

HPA を有効にするところで少しハマりましたが、シュッと Auto Scale が有効にでき AWS の使用料も抑えることができたので便利でした。

本番導入して 10 日程ですが今の所問題は起きてません。

Web CM に出た話

はじめに

既に公開されて一ヶ月経ってしまったのだけれど、ジョージアの Web CM にでたので、そこら辺の話を書いていく。
前職の時に TV 番組や TV CM にちょっと映ってる程度のことはあったのだけれど自分がメインで CM に出るとか初だったので色々面白かった。

そもそもなぜ出ることになったのか？

社内の様子がチラリ。そしてこれの話を持ってきたのは僕だということは社内ではあまり知られていないhttps://t.co/JvH8taW2Nv

— Kotaro Kokubo (@kotarok) 2019年4月29日

上記の経緯で社に話が来て、なんやかんやあって自分になったので出ることになった。
最初に聞いたときはコカコーラの CM かと思ったらコカコーラ社のジョージアの CM だった。

当日の様子

撮影日は 4/1 だったので実はエイプリルフール的なアレだったりするのかもしれないなどと考えていたのだけれど実はそうではなかったらしい。

社内で撮影準備が進められている中で、撮影始まる少し前にプロデューサー(？)っぽい人と話たりリハーサル的に質問に答えたりしたのだけれど下記のようなことを言われた

• この CM をみた人がソフトウェアエンジニアっていう仕事に憧れるようなものにしたい
• どんな流れで質問するか？みたいな奴を事前に渡してはいるけど特に気にしないで聞きたいことがあれば聞いてもらっても良いし自然な感じでやってほしい
• 事前のリハーサルでこのタイミングで二人にこれ聞いてみましょう的な話(サーバって知ってますか？とかの逆質問)

こんな感じのことを話したような気がする。

いざ撮影開始なのだけど撮影現場に行った時に「後藤さんは入りま〜す」パチパチ(拍手)みたいなのをやってもらい TV とかでみたことあるやつや って感動した。

CM みて貰えばわかるんですが、マジで久しぶりにあんなに緊張したなというほど緊張した。(登壇とかの比じゃない)
その結果リハーサルの時に言われたことは全て頭の中から消え失せてしまっていて、今思い返すと自分でも笑える。

飯尾さんも R 指定さんもすごく優しく、また言葉のチョイスとかがマジで凄いなって思った。
撮影の合間も気を使って貰って色々話しかけてくれた。

実際の CM について

www.youtube.com

この中で話している 仕事をしているというよりは遊びに近い感覚 というのは、以前から社内で 1on1 とかやってる時にも何人かには話してたりするので本当にそういう感覚なのだけれど誤解して欲しくはないのは遊びに近い感覚だからと言って真面目にやっていないというわけではない。

最近も 5 年後の minne のエンジニア組織をどうするか？みたいな資料を作ったり、インフラのコスト削減をやったりなどを真面目にやってる。

プロとしての自覚も誇りも持っているので、自分の仕事はきっちりこなしたいと思っているし自分がやると言った仕事に関しては基本的にやりきっている(はずで)だからこそ周りからエンジニアとして信頼して貰っていて今の CTL という職位を任されていると思っている。

それにサービスが成長しなければ自分の楽しい遊び場がなくなってしまうので、より良いものをユーザに提供し多くのユーザに使ってもらうことでそこで発生する新たな問題を技術で解決していくというサイクルに入るためにも事業の成長を技術的にどう推進していけるのか？ということも考えている。

最後に

貴重な経験ができて楽しかったです。基本的にやったことないことはとりあえずやってみるかという精神で生きているので CM 出演の件もやって見てよかったなと。

普段あまり接点がない社の人と話ができたりもあったのでよかった。

公開日の午前中に友達に発見されて LINE で晒されたのでインターネットは凄いなって思いました。

EKS の pod で mackerel-container-agent を動かして監視する

はじめに

EKS is これ

で最近 EKS を触ってアレコレしてるんだけどそのアレコレの一つで mackerel-container-agent 導入してメトリクスを収集するというのがあった。

僕が所属している GMO ペパボでは mackerel をかなり使っていて mackerel 上で一括して見られると便利なので入れた。

EKS なら CloudWatch とかでも取れるのかもしれないけれど、僕がやっている minne というサービスは OpenStack と AWS のハイブリッドなので mackerel に集約されるのが便利なのでした。

導入する

だいたい下記に書いてある。

mackerel.io

上記のマニフェスト例にあるように下記のような yaml を用意する

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  serviceAccouontName: sample-serviceaccount
  containers:
  # ...
  - name: mackerel-container-agent
    image: mackerel/mackerel-container-agent:latest
    imagePullPolicy: Always
    resources:
      limits:
        memory: 128Mi
    env:
      - name: MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT
        value: "0"
      - name: MACKEREL_CONTAINER_PLATFORM
        value: kubernetes
      - name: MACKEREL_APIKEY
        value: <Mackerel APIKey>
      - name: MACKEREL_KUBERNETES_KUBELET_HOST
        valueFrom:
          fieldRef:
            fieldPath: status.hostIP
      - name: MACKEREL_KUBERNETES_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MACKEREL_KUBERNETES_POD_NAME
        valueFrom:
         fieldRef:
            fieldPath: metadata.name

EKS で ここ に書いてある AMI を使用すると --read-only-port が無効な状態になっているので MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT を指定する必要がある。(他にも --read-only-port を有効にして AMI を作成することも可能で https://github.com/awslabs/amazon-eks-ami の issue を漁れば方法がわかるかと)

また、後述する serviceAccountName も設定しておく。

次に RBAC を設定する。
mackerel の document の RBACの設定例をそのまま適応した後に下記の ServiceAccount の yaml を作成し apply する

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-serviceaccount

これで監視ができるようになります。

最後に

RBAC も MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT の指定もしてるのにうまく動かんので EKS に対応してないのか？と思い twitter で呟いたところ中の人から助言を頂き感謝です。

mackerel-container-agent は EKS 対応していないのか？

— shiro16 (@_shiro16) April 16, 2019

結局 deployment で serviceAccouontName を指定してなかっただけっていう落ちだったのですが...