by shigemk2

当面は技術的なことしか書かない

Troubleshoot a Classic Load Balancer: Health Checks

Troubleshoot a Classic Load Balancer: Health Checks

LBがOutOfServiceで Instance has failed at least the Unhealthy Threshold number of health checks consecutively とか出てたらLBからインスタンスのヘルスチェックが失敗しているから、ネットワーク設定とか見直すと良いんじゃないか。同じVPC内でもSGでちゃんと設定しないと疎通しないよ。

メモ セプテーニで分析基盤(Treasure Data)を導入した話 #shinjukugl

www.septeni-holdings.co.jp

  • PYXIS
    • 広告配信最適化
    • 代理店業務改善
    • データ分析
  • いろんなデータ
    • PYXISのデータ
    • セプテーニの各部門DB
    • 外部ベンダーのデータ
    • 媒体社のデータ
  • その問題点とソリューション DWH
    • データの2次利用がしづらい
      • 非構造化データ
        • ビッグデータのストレージ
        • 雑にデータを入れられる
    • データの分散管理
      • データの集約
    • パフォーマンスが悪い
      • 分散処理
        • CSVやJSONなどを横断的に検索する
    • ETL処理の乱立
      • 簡素化 ツール利用
    • 要件すべてを満たしたのがTD(PlazmaDB/Presto)

TDを利用したアーキテクチャ

  • ほとんどが外部サービス
    • S3→Embulk→PlazmaDB→Presto
    • S3
      • 生データをそのまま保存することで運用を少しでも楽にする
      • ファーストにすることでAWSサービスとの応用も楽になる
      • 構造化データは境界付けられたコンテキストに閉じる
      • PYXISのアプリケーション境界の命名にする
      • PATH: TDデータベース名/TDテーブル名/yyyy/MM/yyyymmdd(Embulkで読みやすくするため Athenaのパーティションで指定しやすくするため)
    • Embulk
    • PlazmaDB
    • Presto

TDの領域

  • フルマネージドサービスを利用する
    • インフラの運用コストを削減
    • Treasure Workflow(Digdagのマネージド)
    • Data Connector(Embulkのマネージド)
    • Data Tank(PostgreSQLのマネージド)
    • S3からtd_load
    • 銀の弾丸はない
      • Treasure WorkflowとDigdagの使い分け(TW SQLだけの処理はできない場合Digdagも検討している)
      • Data Connectorでは欲しい集計粒度が得られない→Embulkプラグインの組み込みと開発

TDを利用した業務フロー

  1. データ蓄積(開発者がデータを格納)
  2. データ分析/価値検証(非エンジニアによるTDのGUIを利用)
  3. Digdagによるオートメーション化(開発者が管理 データアナリストとシームレスに業務連携する)

TDを選択してよかった点

  • 分析業務に集中する
    • フルマネージドな分析基盤をスピーディに手に入る
    • AWSやGCPを自前で構築するとサービスの知見を知った上で保守運用する必要がある
  • 外部システムとの連携が容易
    • データのインポート/エクスポートのエコシステムが充実
    • データベースやファイルサーバーとの疎通のバリエーションが多い
  • データ分析/価値検証までのスピード感と安心感
    • データの蓄積さえすればデータアナリストが分析する状態に
    • 従量課金じゃないので無邪気なselectクエリとかを投げてもクラウド破産しない

メモ 動画系メディア会社で行われているETLの実際 #shinjukugl

メモ 動画系メディア会社で行われているETLの実際 #shinjukugl

  • デリッシュキッチンのアレ

PoC

  • SSOTに則ったアーキにしたかった
  • API(Golang) Adjust Firebase DWH[Athena BQ] 可視化
    • AdjustのデータとかAPIのデータとかが結合化出来ない(SSOTじゃない)
    • Athena スキャン従量課金
  • SSOTが実現されていること
    • 簡素な分析SQL
    • window関数やJOINの除去
    • スキャンを気にしない
    • スキーマレスであること
  • 白羽の矢: TreasureData
    • リソース課金
    • ポストバックが出来るAPIが用意されていること
    • スキーマレスDB
    • フルマネージドなbulk import/job scheduler

ETL 事例紹介

  • https://en.wikipedia.org/wiki/Extract,transform,load
    • Firebase Analytics
      • BaaSツール
      • A/Bテストとかプッシュ通知とかイベントログ計測とか
      • BQにイベント計測ログが連携可能
      • BQを使っているのでスキャン量とSQLの難読化が問題であった
  • FireBase→BQ→GCS→(embulk)→S3→(embulk)→TD
  • TreasureWorkflow
  • Embulk on EMR
    • MapReduce Executorを利用してHadoopクラスター上で分散実行
    • 2ステップ
      • log用のjarを事前ロード
      • MapReduce Executorを利用してEmbulkを起動する
      • 大量取り込みができる
  • Embulk 実行計画 1レコード1イベントで列指向変換
    1. AVRO→JSON
    2. JSON→PlazmaDB

Embulkプラグインの組み合わせ

  • Embulkプラグインがないので仕方なく作って組み合わせる
    • Java8との格闘
    • 差分連携 − Firebase→BQ
    • intraday 今日のデータ
    • 差分連携を利用して過去ログ積み上げ
  • 全量は昨日までのデータ + 今日のデータ
    • 今日のデータ = 全量 - 昨日までのデータ
    • RedShiftでも出来るけどEmbulkで実現したい
  • parser-firebase_avro
    • akka + redis
  • 多種多様なETLをEmbulkプラグインで
  • なかったら作る
    • Scala勉強しておくとEmbulkプラグインの作成に役立つ

メモ Embulkの歴史、過去・現在、これから #shinjukugl

メモ Embulkの歴史、過去・現在、これから #shinjukugl

embulkとは

  • embulk fluentdのバッチ
  • プラグインアーキテクチャ JRuby/Java/Scala/Kotlin
  • 並列処理 並行処理
  • guess
  • リトライ レジューム
  • yamlベース

-2015

  • プラグインの数はfluentdよりは少ない
  • 組み込みプラグイン覚書
  • コマンドヘルプ

  • さまざまな人々の貢献

    • sakamaさん
      • BQ用プラグイン BQにデータをアップロードできる
      • 組み込みCSVフォーマッターの修正
    • hito4_tさん
      • JDBCまわりの大幅な回収
      • Oracle/SQLServerまわり
    • civitaspoさん
      • JSONまわりのプラグインを作成
    • sonotsさん
      • embulk後の定番フィルターを作成
    • その頃embulk-parser-apache-logとか作っていた
  • イベント開催
    • embulk meetup tokyo
    • RubyBiz 第1回グランプリ受賞
  • 要望
    • 設定ファイル共有化: Liquid(環境変数読み込みが可能に)
    • Array/Hash対応

-2016

  • ワークフローエンジン digdag(2016/2)
    • YAMLライクなDSL
    • digdag-plugin-ssh
    • digdag-plugin-mysql
  • その頃
    • embulk-filter-null_string
    • embulk-filter-calc
    • etc
  • WebDBとかでの紹介
    • Excelプラグインが脚光を浴びる

改善

  • 複雑なブートストラップの改善とか
  • 速度改善
    • JRubyおそい→Java
    • Timestamp遅い問題、0.8.27で修正済み
  • 島田さん
    • EMRを使ったデータ作成

これから

  • Java8
  • バイナリタイプサポート
  • Pure Java Plugin
  • reporter plugin
    • ロードした件数がわかるように
  • データ分析基盤構築入門

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

  • 作者: 鈴木健太,吉田健太郎,大谷純,道井俊介
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/09/21
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

dired-jump

Jump to Dired buffer corresponding to current buffer. If in a file, Dired the current directory and move to file’s line. If in Dired already, pop up a level and goto old directory’s line. In case the proper Dired file line cannot be found, refresh the dired buffer and try again.

今のバッファのdiredに飛ぶ。一応C-x C-jを割り当てている。

emacs.stackexchange.com

ブログを毎日書き始めて丸6年が経った

f:id:shigemk2:20170918142723p:plain

時の流れは早いもので、毎日ブログを書くようになってから丸6年が年が経った。勤めている会社の決算期ともかぶるので、この1年でやったことや反省などをつらつら雑に書く。

業務でやったことと

  • 某システムの看取り
  • 某システムの作り直し
  • Hadoop
    • EMR
    • Presto
  • Zabbix
    • CloudWatch
    • fluentd
  • Ansible
  • Scala
    • Play Framework
  • React.js
  • kuroko2

どちらかといえば保守運用な業務を中心にちょくちょく設計とか実装とかやってた気がする。AWSのオペレーションは雑に覚えた。必要に迫られるのは非常に大切。監視設計はちゃんとしようね。閾値の設定もそうだけど、どこをどういうルールでモニタリングするかを予め決めておくのはとても大切だよ。あとCacooでもなんでもいいからネットワーク図は残そう。図に対して細かくレビューができないのがCacooのちょっと不便なところ。スケジュールは多めに見積もらないとだめだよ。無邪気にHueとかでselectするだけの業務ならHadoopのエコシステムは全く意識しなくていいけど、我々はエンジニアなので。

反省点

すごく月並みだけど、未完成でもいいから早め早めのアウトプットを心がけるのはすごく大事だねって思う。やっぱりなんでもいいので気づいたことはどこかに残しておきたい。読んだ本の内容をちょいちょい忘れるので、1つのキーワードかセンテンスレベルで頭に残しておくようなインプットを心がけていきたい。

あと人に何かをわかりやすく説明するスキルを身につける必要がある。

業務以外でやったこと

発表

ここ1年、勉強会へはそんなに行ってない。どちらかといえば発表しに行くスタンスのみを貫いている。別にお酒飲めないしあとでスライド見たら事足りる感じになっちゃってるので。

OSS

2016年10月から2017年9月までのプルリクの一覧。マージされずにクローズされちゃったりしたのもあるけど、年間で30くらいは出した。多いのか少ないのかでいうとよくわからない。ガチのコミッターに比べるとカスみたいな物量なので、ガチのコミッターになりたい。

Pull Requests · Homebrew/homebrew-core · GitHub

Pull Requests · aws/aws-cli · GitHub

Pull Requests · cookpad/kuroko2 · GitHub

Pull Requests · CyberAgent/patriot-workflow-scheduler · GitHub

Pull Requests · atykhonov/google-translate · GitHub

Pull Requests · scalikejdbc/scalikejdbc · GitHub

Add zshrc and zshenv detection to sh-mode (bug#25217) · emacs-mirror/emacs@a8a24b5 · GitHub

業務で使っているかどうかは問わず、ちょいちょい色んな所にIssueやプルリクエストを出すようになったと思う。 機能追加やリファクタも大事だけど、ドキュメントやtypoの修正とか、ライブラリのバージョンアップデートとかも大切。とはいえもっと高度なプルリクを出していきたいけど、「高度なプルリクを出したい」じゃなくって、「もっと使い倒して開発していきたい」っていう気持ちに切り替えている。

「これ不便だな」と思ったらもっと積極的に直していかないとOSSが消滅してしまうから、簡単なのでいいから「これ不便だな」とか「これ間違っているな」とか思ったらどんどんプルリク出していく流れは引き続きやっていきたい。

本を出した

正直あんまり覚えていない。「薄い本を出してみたい」という軽い気持ちで出てみたものの、技術書典に限らず即売会は、どちらかといえば仲間内で集まってワイワイするのが主目的であって、ワイワイするのがあんまり好きじゃない自分には不向きなイベントだったような気がする。

一応DL販売を(なぜかDLsiteで)やっているが、買わなくてもいいです。

なんか書きたいものがあったらやるかもね。でもどっちかっていうと1年したら腐る情報よりも何年経っても質の下がらない情報を提供したい。

所感とこれから

OSSについては、良い流れになってきてるんじゃないですかね。反面、業務で特にこれをやりたい、っていうのがあんまりないのはよくないかも。目の前のタスクをどんどん拾って学んでいくスタイルが続いていくと思う。

open-junk-file 使い分け

github.com

人によってはあんまり好きじゃないらしいopen-junk-fileで、こっちはjunkの下に、こっちはmemoの下に、みたいなことをやりたいときのemacs lisp

(require 'open-junk-file)
(setq open-junk-file-format "~/junk/%Y/%m/%d-%H%M%S.")
(global-set-key (kbd "C-x C-z") 'open-junk-file)

(defun open-junk-file-with-d ()
  (interactive)
  (setq open-junk-file-format-with-d "~/memo/%Y/%m/%d/%H%M%S.md")
  (open-junk-file open-junk-file-format-with-d))

(global-set-key (kbd "C-x z") 'open-junk-file-with-d)

spring-boot run with environment

環境指定のspring-boot run

mvn spring-boot:run -Drun.jvmArguments="-Dspring.profiles.active=production"

環境を指定する

なんかまあこんな感じ。

src/main/java/Example.java

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.*;
import org.springframework.boot.autoconfigure.*;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
import org.springframework.core.env.Environment;
import org.springframework.web.bind.annotation.*;

@RestController
@EnableAutoConfiguration
@Configuration
@PropertySource("classpath:/config/application.yml")
public class Example {

    @Autowired
    private Environment env;

    @RequestMapping("/")
    String home() {
        return env.getProperty("foo.bar");
    }

    public static void main(String[] args) throws Exception {
        SpringApplication.run(Example.class, args);
    }

}

src/main/resources/config/application.yml

foo:
    bar: "hello, development!"

Aurora FAQ

Aurora FAQ

  • 10 GB 単位で最大 64 TB まで、データベースのパフォーマンスに影響を与えずに拡張
  • 予めストレージをプロビジョニングする必要が無いので、とりあえずディスクアラート的なところは心配しなくていい(はず。64TB超えるようなデータを保存するようなら話は別だけど)