progrhyme's tech blog

主にIT関連の技術メモ

Ruby Hack Challengeもくもく会 #5 に参加した

一昨日、Ruby Hack Challengeもくもく会に参加してきました。

初回のCookpad Ruby Hack Challengeは昨年の8月末でしたね。
当時から興味のあるイベントだったのですが、記憶によれば、予定が合わなかったり抽選で漏れたり諦めたりしたようです。

そんなわけで、初RHCでした。

事前準備

空手で行っても資料を元にもくもく作業はできそうでしたが、一応前日に少しだけ準備して臨みました。

GitHubに公開されているRHCの資料を読みながら、手順をなぞってRubyMac上でビルドしたり、C言語の開発環境を整えたり、といった作業をしました。

当日の流れ

会場はCookpadさんの12Fオフィスでした。
キッチンのある広いフリースペース的な場所で、少し大きめの勉強会などでも使われていると思いますが、今回は人数が少なめだったこともあって、1つのテーブルを囲んでみんなでもくもく作業しました。

自分は開始時刻の18:30ごろに到着したのですが、既に@ko1さん含む4名前後の方がいらっしゃってました。

PCを取り出すと、もくもくとRHC資料の続きを読みながら、途中の演習問題を解いていきました。
発展演習問題などは一旦すっ飛ばしつつも、一応最後の 5_performance.md まで読み切ったところで時間切れとなりました。

その間にばらばらと参加者が集まり、終了間際の21:00過ぎになってようやく全員で軽い自己紹介を行いました。

MacにおけるC言語の開発環境について

とても久しぶりにC言語のコードを書くことになったので、開発環境を整える必要がありました。

自分の短いRuby歴(2年弱)では、ずっとVimで開発していましたが、型のある言語だとIDEの支援を受けた方が効率が良いだろうと思っています。

そんなわけでIDEを検討したところ、まあMacだとXcodeがスタンダードなのかなと思いつつ、最近流行りのVS Codeを試したい気持ちになったので、今回はこちらを使ってみました。
私の観測範囲では、VS CodeはJavaScript界隈などで人気が高まっている気がしますが、Rubyもextensionがありますし、上手くすればなんでもVS Codeで書けるような気もします。

もくもく会までにバッチリ使い込むには至りませんですが、コードの読み書きでそれなりに支援を得られるぐらいにはなりました。

もう少しVS Codeを継続してみようかなと思っていますが、Mac上でのC言語開発について、良い情報をお持ちの方はお知らせ下さい。

gdbの代わりにlldbを使った

VS Code上でデバッグするまでは行かなかったのですが、rubyをビルドするためのmakeタスクで make gdbmake lldb が用意されています。 実行するとソースコードディレクトリに置いた test.rb を、その場でビルドしたruby(miniruby)を使ってgdb or lldbで実行してくれます。

初め、Macgdbを動かそうと少し試していたのですが、結局上手く行きませんでした。*1

lldbLLVMのライブラリを利用したより高機能なデバッガで、どうもMacではこちらを使った方が筋が良さそうです。

今後について

@ko1さんによれば、6月もRHCのイベント(おそらくまたもくもく会でしょうか)が開催されるそうです。

今回、私は下準備的なことしかできなかったので、できればまずは何か1つコントリビュートしてみたいなと思っています。
というわけで、来月以降も機会が合えば是非参加したいと思っています。

終わりに

イベントの開催、ありがとうございました!

GitLab Meetup Tokyo #7 に行ってきた

4/10にこちらのイベントに行ってきました。

気づいたときには一般参加枠が埋まっていたので、ブログ枠で参加しました。
…ということもあって、こうして記事を書いております。

最近GitLabを使うことが多いのですが、今回はコアな方々の話を聞けたり、今まで知らなかった機能やGitLabの思想にも触れることができて有意義でした。

  • はじめに
  • 発表スライド
  • 感想
  • 終わりに
  • 聴講メモ
    • Keynote「GitLabによるComplete DevOps」
    • LT①「How does GitLab manage git repositories?」
    • LT②「GitLabのイシュートラッカー活用術」
    • LT③「GitLab CI & Docker in Docker」
    • LT④「カップラボ」
    • LT⑤「State of Community Contributions to GitLab & GitLab 11.0」
    • スポンサーLT クリエーションラインさん

はじめに

会場はサイボウズさんでした。

f:id:progrhyme:20180411000200j:plain

全体で90名ほどの参加予定でしたが、席はほぼ満席で、活気のある雰囲気でスタートしました。

始めに、GitLab Tokyo / GitLab JPの案内がありました。

Slackはどうやって入るのだろうと思ったのですが、HerokuでSlackinが動いているようですね。 検索すると見つかると思います。

発表スライド

Connpassに上がっているものもありますが、捕捉したものはここにも上げておきます。
(※随時更新します。)

Keynote「GitLabによるComplete DevOps」@shkitayama

LT①「How does GitLab manage git repositories?」@sotayamashita

LT②「GitLabのイシュートラッカー活用術」@jumpyoshi

LT③「GitLab CI & Docker in Docker」@toricls

LT④「カップラボ」@t_nakayama0714

LT⑤「State of Community Contributions to GitLab & GitLab 11.0」@tnir

感想

詳細な聴講メモは記事末尾に載せておきますが、ここでは印象深かった点を中心に簡単に感想を述べます。

続きを読む

Hugoのイケてるドキュメンテーション用Theme "Learn"と"DocDock"

はじめに

3年前(後述)に探したときは良いものが見つけられなかったのですが、時代は進んで便利なThemeが登場しているようです。
ドキュメントをHugoで作ると、Markdownでソースを管理できるのが良いですね。

この記事では主に"Learn"と"DocDock"という2つのThemeを紹介します。

Learn

Learn Theme for Hugo :: Documentation for Hugo Learn Theme

上がデモサイトにもなっています。

簡単に特長を紹介しておきます:

他にもいくつか機能がありますので、上のサイトを確認ください。

DocDock

DocDock Documentation

こちらは、Learnのフォークですが、作者はLearnにもコントリビュートしているようです。
LearnのREADMEにcreditが載せられています

Learnと違って多言語対応はしていませんが、独自機能としてreveal.jsによるスライド生成機能があるようです。

Bootie Docsとの比較

私自身も、3年前にbootie-docsというドキュメンテーション用のThemeを作って、ほそぼそとメンテを続けています。

正直に言って、bootie-docsよりもLearnやDocDockの方が機能が豊富で良さそうです^^;

特に、ドキュメントが増えてくると、メニューを一階層しか持てないBootie Docsでは苦しくなってくるかもしれません。

その他のTheme

ドキュメンテーション用のThemeは下のページを見ると他にもあります。

https://themes.gohugo.io/tags/documentation

ざっと見たところ、APIドキュメントを書くときはDocuAPIもよさそうだなと思いました。
先に挙げた2つのThemeは一般的な用途で使いやすそうです。

結びに

次にソフトウェアドキュメントを書くときには、LearnかDocDockのいずれかを試してみたいと思います。

3年前について

参考

Tour of Scalaを一巡りした

Tour of Scalaとは?

Tour of Scalaは、Scala公式サイトで提供されているScala初学者向けのチュートリアル的教材コンテンツです。
Golangの「A Tour of Go」のようなものですね。

Motivation

これに取り組んだ大きな理由としては2つあります。

  • Scalaが最近、身近でよく使われる言語になった。
  • 関数型言語をイチから学んでみたかった。

前者については、自分自身がScalaのコードを書く機会は今のところほぼないのですが、書けるようになれば話は変わってくるかもしれません。

後者については、意識して取り組んでいたのは、かつて大学の授業でSchemeを触っていた頃ぐらいでしょうか。
他にも、例えばRubyを書いていて知らず知らずの内に関数型プログラミング的なアプローチを取っていたことはあるかもしれませんが、どういうのがそれなのかと聞かれると明言しかねる状態です。

然るに、関数型プログラミングはやはり大きなパラダイムであるので、これを学んでおくことは今後も必ず役立つだろうと思いました。

どのように取り組んだか

Scala開発のための環境構築ログはこちら
IntelliJ IDEAでワークシートを作り、コードを貼って動作確認することが多かったです。

3/21〜24の4日間でTourを一巡し終えました。

以下は初学者向けのお役立ち情報です:

所感

Scalaについて、まだ機能の全貌は掴めていませんが、implicit機構など想像以上にパワフルな言語であることはわかりました。
一方で、LL並に簡潔に書けるような省略記法やシンタックス・シュガーがあることもわかりました。

関数型プログラミングについても、主要な登場人物らしき方々(第一級オブジェクトとしての関数、高階関数、カリー化、…)は現れたので、さわりぐらいは掴めたのかなと思います。

ただ、Tourを一巡しただけでは、特に関数型プログラミングについては学び足りないと感じました。

今後

そこで、上にも挙げたドワンゴのScala研修テキストの中で紹介されていた『Scala関数型デザイン&プログラミング』を購入することにしました。
こちらは、Kindle版だと50% OFFで購入することができました。

Scala スケーラブルプログラミング』(通称、「コップ本」)でないのはなぜかというと、どちらかといえば、Scalaよりも関数型プログラミングの方を学びたいからです。

関数型プログラミングを学ぶ上では他にも良書がありそうですが、ひとまずはScalaの学習も兼ねて、こちらの本で勉強を進めようと思います。

TREASURE DATA社主催のSRE勉強会に行ってきた

昨晩、こちらの勉強会にお邪魔してきました。

以下は発表概要と所感です。

※発表資料はまだ公開されていないものもあるようですが、捕捉したらなるべくこの記事にも載せます。

BUILDING RELIABLE SERVICES

TD社のSRE Chris Maxwellさん(@WrathOfChris)の発表。

TDはかなり色々なサービスがあって、それぞれデプロイ方法や構成方法がバラバラでだいぶカオスな状況だったけど、最近スタンダードを作るようにしていて、段々よくなってきている、というような趣旨だった。

英語の発表だったけど、とてもきれいな発音で聴きとりやすかった。

prismatix SREチーム立ち上げからの1年間

クラスメソッドの望月さん(@Canelmo)の発表。

prismatixというのは、クラスメソッドさんの子会社で提供しているサービスで、ECとCRMを簡単に構築できるAPIプラットフォームらしい。
お客さん向けにそれぞれAWSアカウントを作って提供しているので、複数アカウントの管理・運用をいかに効率的にするかが肝、といった話があった。

特に興味深かったのは以下の点:

  • CloudWatch Logsにはアラートに必要なログだけを入れ、全ログはS3に保存している。
    • CloudWatch Logsに全ログを保存すると高くつく
    • S3に保存していれば、バケットの参照を許可していれば一箇所からAthenaでクエリすることができる。
  • 監視にDataDogを使っている。DataDogは複数AWSアカウントに対応していて便利。

あと、クレデンシャルの管理はどうしているのだろう? と気になったので質問してみた。
これは「DSLとSSM Parameter Storeで管理していて、誰が実行しても同じ環境が構築できる」という話があったので。
回答としては、「クレデンシャル情報もSSM Parameter StoreのSecret Stringで保存している。誰がそこにアクセスできるかは別途(おそらくIAMで)管理している」というような内容だった。

スマートニュースの進化の歴史

スマートニュースの真幡さん(@mahata)の発表。

スマートニュースでのDevOpsやMicroservicesに対する取り組みについての話で、良い話だけでなくて悪い話もあって、わかりみがあった。
サービスが一定の規模を越えるとIaaSとエンタープライズ契約を結んだ方が良いというのは、個人的には頷ける話だった。

また、面白かったネタとしてSlackによるローカライズbotの話があった。
これはSlackの投稿に各国の国旗をリアクションで付けると、その投稿に対してスレッド返信の形で、その国の言語で翻訳した結果をbotが投稿するというものだ。
とても便利そうだと思った。

世界最大のレシピ動画サービス「クラシル」を支えるインフラ

delyの深尾さんの発表。

深尾さんは元イタリア料理人だそうだ。

氏がクラシルにjoinしてから、どのようにインフラの改善を行い、SRE的なプラクティスを実践しているのかを発表した。
なんでもやるわけじゃなくて、人員リソースを考慮してやる・やらないをはっきり決めているのがとても良いなと思った。

まとめ

各社のSREに関する取り組みを聞けて良い刺激を得られた。
Web系を中心に日本のテック業界にもSREのプラクティスが広まってきているように感じる。

TECH PLAYに行ったのは2回目だけど、相変わらずきれいで雰囲気の良い会場だった。

今回は軽食ビュッフェと飲み物が豊富に提供されて、飲食を楽しみながら聴講することができた。

主催してくださったTREASURE DATAさん、ありがとうございました!!

おまけ

以下は会場で取った雑なメモです。
ほとんど清書してないので、気が向いたら見てください。

Chris Maxwell @WrathOfChris

SRE

BUILDING RELIABLE SERVICES

  • Why?
    • Building Reliable Services
    • cannot buy reliability
    • tools
  • daily workload
    • 400,000+ queries / day
    • 1 M+ events / sec
    • 15+ Trillion Rows / day
  • runtime convergence
    • cookbooks ... Chef
  • Our hero
    • infra engineer & SRE
    • increase velocity
      • faster than weekly deployments
      • more sites
  • complex platform
  • Service Delivery is hard
    • measure reliability
    • foundation is dirty work
  • Wisdom from outsie
    • simple first
    • on experts and advice
  • mentor returns
    • chunks ... 7
  • first changes
    • standard deployment targets
    • standard startup services
    • Derek Coolison
  • hard work ahead
  • wrap up service
    • autoscale group
    • Presto
    • Simple is Hard
      • 3 sources of configuration truth
  • Didn't have time for API
  • 6 friends for the journey
    • Autoscaling
    • App Load Balancer
    • EC2 Security Group
    • Code Deploy
    • Route 53
    • IAM role
  • More friends
    • trust team
    • Don't solve problems with software that should be solved with talking
  • Mentor returns
    • tools express process
    • process should uplift the organization
  • Service Tool
    • 6 infra api w/ MVP tools
      • Leverage immediate gain ... orchestration
      • paying interest ... learning team
  • Services First
    • any engineer can
      • release frontend/backend
  • Complexity ... enemy
    • cut & paste and grow ...
    • unclear boundaries
  • Migrate
    • simplifying complex
    • many transitional changes
    • precision replacement
  • Process
    • Legacy Process
    • Transition
  • Standard Services First
    • With standards, exceptions are hard
  • 新しいやり方でリリースできた!
  • remaining services
  • The way home
    • Best Practices
      • Standard services
  • Remaining services
    • service improvements
    • support config management
    • strategy to improve
  • heroes
    • Yuu Yamashita
    • Yuki Ito
    • Kokubun
    • Chris

prismatix SREチーム立ち上げからの1年

クラスメソッド望月

  • @Canelmo
    • prismatix SREチームリーダー
    • AWS認定SA / DevOps Professional
  • prismatixの紹介
  • アーキテクチャ
  • リリースと
  • Developers.IO
  • prismatix
    • ECとCRMのためのAPIプラットフォーム
    • 2016/5 開発開始
    • 2016/12 本番リリース
    • 2017/1 に1人チーム
    • 2018/3 3人体制
  • システム特性
    • スパイクアクセス
      • 予測可能/不能な大量アクセス
        • 予告済みのセール
        • SNS
        • 在庫洗替による大量更新
    • 商品検索
      • ユーザーは商品を探しにくる
      • 検索がメインのトラフィック
      • 大きな負荷、Network I/O
    • 注文/決済
  • 技術スタック
    • Java8 w/ Spring Boot + Docker
    • Elasticsearch by AWS
    • Kinesis
    • RDS for MySQL (Aurora)
    • AWS DynamoDB
    • Redis (AWS ElastiCache)
  • 全文検索したいデータをKinesisに流してElasticsearch Serviceに登録
  • クライアントごとに個別の環境をセットアップ
    • AWSアカウントも独立させる
    • デメリット:
      • 新規案件が増えるたび、環境も増える
  • JOIN時のデプロイ方法
    • AWS EB
    • GitHub + CircleCI
    • 開発者が個人の端末からデプロイ
    • CloudFormation ... デプロイ
      • パラメータ定義を各自が個人端末で管理
      • プロジェクトJOIN時、誰かからもらう
  • 改善: 完全に再現可能なインフラにする
    • シングルテナント
    • セットアップ内容を完全に自動化
    • 環境ごとの差異が発生しないように
    • 何かあればrebuildできるという安心感
    • インフラのテストにも使える
  • デプロイの見直し
    • Beanstalk から ECSへの移行
    • CircleCIからビルド時にImageをPush
    • 環境変数をSSM Parameter StoreとDSLで管理
      • DSLでParameter Storeの値登録
  • これからやりたいこと
    • インフラCI
    • Elasticsearch index構築高速化
  • 監視ツール
    • 社内共通の監視ツール
    • 取りたいメトリクスが取りきれてなかった
    • DataDog
      • 複数のAWSアカウントの管理にも対応
    • AWS IntegrationとDocker Integrationが便利
  • 監視対象
    • CloudWatchメトリクスとOSメトリクス
  • ログ周り
    • JOIN時
      • EB => CloudWatch Logsに送信
      • いくつかのログはOSに入らないと見えない
    • 変更後
      • ECS Cluster
        • Log Driver -> fluentd
          • S3にログ保存
          • LBにログを飛ばす
            • fluentd
              • CloudWatch Logs
              • 他 etc
  • CloudWatch Logs
    • 割りとお高い
    • 通知が必要なエラーを送る
  • Athena
    • S3上のログがJSON
    • partitionを切る
      • 月ごと <= 月初にバッチで
    • 同時接続数がデフォルトだと5なので注意
    • 他のAWS S3も許可してれば見える
  • 質問:
    • credentialの管理
      • Parameter Store
        • 誰が操作できるかを別途管理
    • cloudtrail logs
      • 各アカウントごと
    • Elasticsearchの性能劣化について
      • つらいことはある
    • K8s考えなかったのか?
      • AWS使う前提だった

スマートニュースの進化の歴史

  • @mahata
    • Software Engineer
    • ややインフラ寄り
    • ニュース配信基盤担当
  • SmartNews
    • クーポンチャンネル
  • オフィス風景
  • ニュース配信基盤
    • 監視
      • Data Dog
    • 配信
      • Cloud Search
    • 検索
    • 収集
  • スマートニュース特有のチャレンジ
    • 日米で開発拠点を分散させる難しさ
      • 言語の壁
      • 空気感(?)の違い
  • 言語の壁
    • Slackで英語で話すチャンネルを作る
      • 全員日本人でも英語で
    • botローカライズ難しい
    • Qiita:Team
      • tag:english
    • 便利ツールまじ便利
  • 半年に1度は海外ワーク!スマニューならカンファレンスも
  • インフラの構成管理
    • 避けたいこと ... Dev vs. Ops
  • インフラの構成管理
    • Dev ... コードを書くことでインフラを設定
    • Ops ... コードレビューでインフラを安定化。コードも書く
      • => SRE
  • ツール:
    • Terraform
    • Itamae + Fabric (+ カスタム Fabfile)
  • IaaSとエンタープライズ契約
    • AWS
    • ある程度の規模を超えたら必須ではないか
    • メリット:
      • 雑に質問できる
        • 必要な情報は先方が教えてくれる
      • 普通は知りえないことを教えてくれる
        • ex) VMが載っているホストの情報
      • 普通は知りえないLimitを教えてくれる
  • Microservices
    • 良い話
      • サービス分割 / チーム分割
        • 違う技術を選択可能
        • サービスごとにスケール可能
        • 小さい単位でのリリースが可能
    • 悪い話
      • サービス間での技術の流用が困難
      • チーム間での知識の分断
      • /api/v1/x, /api/v2/x
    • つらい話
      • 脆弱性のあるAMI
      • 更新
      • サービスごとにLCを設定
    • 行き過ぎたMicroservices
      • サービス数 > エンジニア数
      • あるエンジニアが退職
      • レガシーコード誕生!
    • 落とし所
  • 社内コミュニケーションHacks
    • 読書会 ... SRE本
    • Work Out Loud
      • 人目につくところで開催する
      • 資料も人目にふれるところに置く
      • 参加者が増える
    • お寿司
    • 勉強会に予算を付ける
  • これから解決すべき課題
    • システム障害に強い体制づくり
      • 適切なメトリクスの取得
      • 適切なアラート設定
    • システム障害対応あるある
      • すごい人
  • Q&A:
    • Chaos Monkeyとか使ってる?
      • 使わなくても色々起きてる

現場で使えるSite Reliability Engineering

Fukao Moto / dely

  • ブンさん
    • 元料理人
  • クラシル
    • 1分でレシピがわかる
    • 2017年メディア露出多い
    • 昨年末に1,000万ダウンロード
  • 1人目のSRE
    • Web / DBはシングル構成
    • 監視未整備
  • スケーラビリティ
    • スケールアウト
    • 負荷テスト
    • サイジング
      • スケールアウトできない:
        • 例) RDB, ジョブ
      • ディスクサイズも1年を目安に 
  • 可用性
    • SPOFをなくす
    • バックアップ
    • 自動復旧
    • モニタリング
  • 監視メトリクス
    • サチュレーション
  • キャッシュ
  • プロトコル
  • 変更に強い設計:
    • ログ収集基盤:
      • fluentd + forrest
    • 構成管理
      • コード化 & DRY
  • SLO
    • なぜSLOが重要か?
      • 全アラートに対応?
      • 信頼性をあげる作業には終わりがない
      • 減点方式から目標達成方式に転換
  • どうやってSLOを決めるか
    • ユーザ目線
    • CloudWatch Metrics
      • パーセンタイル値
  • Infrastructure as Code
    • DRY原則
    • ツールやFWは任意
    • タグで管理
    • 論理名と物理名
  • DevOps
  • イベント対応
    • Webのトップページを守ろう
      • スマステ
        • 予期せぬ数十万UU
        • 新規ユーザ獲得
        • 遅いページで全体が詰まる
      • Nginx
        • pathによってupstreamをグルーピング
        • cache
    • コミュニケーションロス
      • イベント対応レベルを決める
  • ポストモーテムに書くこと
    • タイムライン
    • 良かったこと
    • 悪かったこと
    • 幸運だったこと
    • 書かないこと
      • 根本原因分析
      • 再発防止策 => Issueに
      • ※犯人探しはしない
  • TODO管理
  • SRE Principles
    • 主体的に行動できるように
    • 得意分野を活かす(生産性)
    • Why, Whatを共有
      • 3W, 1Hはあえて共有しない
        • Whenは決めない。Whyがわかってれば優先順位はわかるはず
      • 何をやらないかを定義 ★
  • ミッション
    • 意思決定に必要な指標を取得し、正確性を保証する
  • SREミーティング
    • 会議コストを最小化
    • アジェンダを事前共有
    • 週次/隔週/月次
    • 金曜に実施 ... 週末に準備できる
  • リスクマネジメント:
    • 何もやってないとまずい
    • 小さなコストで大きなリスク
  • APOLLO Program
    • 障害対応訓練
  • まとめ
    • 費用対効果を重視
    • スケーラビリティの確保
    • スコープ ... やらないことの選択
    • WHYを共有
  • Q&A
    • 障害対応の再現方法
    • 根本原因を調べないと再発防止できないのでは?
      • 根本原因を調べることもIssueにする

吉祥寺.pm #13 で医療Webサービスの基盤技術について発表してきた

昨夜、吉祥寺.pmというテックイベントで発表してきました。

私の発表資料は下になります。

現職では、多様な医療Webサービスを展開しているわけですが、それらのシステムの構成要素であったり、裏側のインフラ事情であったり、開発で利用しているツールなどを幅広く紹介した形です。

もう少し自分自身の業務内容に近づけた方が良かっただろうか、という思いもありましたが、懇親会などで「プロダクション環境で動作しているシステムの事例として参考になった」というような感想も頂き、これはこれで良かったかなと思いました。

私以外の発表で行くと、エンジニアの健康の話や、プログラミングの設計、Webアーキテクチャーを実装して学んだ話と、吉祥寺.pmらしい多彩な内容だったと思います。
もちろん、Perlの話もありました(笑)

発表やLTの資料は、私のものも含めて上述のConnpassのページにUpされるようです。

懇親会にも参加しました。
「オフラインでお会いするのは初めてですね」という方も何名かいらっしゃいました。色々と面白い話が聞けて良かったです。

このような機会を頂き、ありがとうございました。

次回の吉祥寺.pmは5月に開催予定とのこと。
都合がつく限りなるべく参加したいなと思います。

余談

前回、吉祥寺.pmで発表したのは約2年半前のことだったようです。

当時とはハンドルネームが変わったため、呼び方で戸惑わせてしまったようです。*1

*1:「きいあむさんと呼んでしまう」と言われました。すいません。。(汗)

Redash Meetup #0に参加した

RedashはOSSのハンディなBIツールとして、ちょくちょく名前を聞いて気になっていましたが、あいにくこれまで触ってみる機会がありませんでした。

そんな折にこちらのハンズオンを見かけたので、行ってみることにしました。

ハンズオンは、@kakakakakkuさんがGitHubに公開して下さっている下の資料に基いて実施しました。

丁寧に作られているので、今回のMeetupに参加していない人でも、こちらに沿って作業すると一通り内容が掴めるだろうと思います。

ハンズオン実施項目

上の資料の目次相当のものを書き下します:

  • Redashをローカルマシン上でセットアップ by Docker Compose
  • データソース設定 : MySQL
  • クエリ作成
  • クエリ結果をグラフ化(Visualize)
    • Counter
    • 円グラフ
    • 棒グラフ
  • ダッシュボードの作成
    • グルーピングについて
  • パラメータ付きクエリの作成
  • フィルタ機能
  • クエリスニペット
  • クエリ結果にHTML埋め込み(色を付ける)
  • クエリ結果にURLを含める / リンク集の作成
  • クエリ結果をダウンロードする
  • クエリをフォークする
  • Slackアラートを設定する

割りとサクサク進んで、やや時間が余ったので、追加で以下のようなこともやりました:

  • 時系列グラフの作成
  • Redash内部のPostgreSQLをデータソースに追加してクエリ作成
  • 一般ユーザの追加
  • 管理画面へのアクセス

Q&A

いくつか運用に関して気になったことなどを講師の方々に聞いてみました。

  • Redashサーバをどうやって立てていますか?
  • 権限管理どうしてますか?
    • Redashのデータソースに対する権限設定はFull AccessかRead Onlyしかない
      • Read Onlyにするとクエリ実行すらできない => あまり実用的ではなさそう
    • データソースにするDBMS側で権限設定している。
    • CLIとか駆使すればデータソースに対して細かい権限設定もできるっぽい。誰かがアドベントカレンダーに書くらしい

その他こぼれ話

  • トラブル事例:
    • ディスク容量の逼迫 ... 大きな結果セットのクエリが投げられ、Redash内部のPostgreSQL側にキャッシュされてディスク容量が逼迫した
      • 対策として、キャッシュのパージ設定を調整することができる
  • Undocumentedな機能が色々ある
    • JSONを返すURLとか、シェルコマンドとかもデータソースに使えるとか

感想

BIツールをあまりハードに使い込んだことはないのですが、Redashは便利な機能が色々揃っていて、セットアップも簡単で良いツールだなと思いました。
権限管理など、大規模に使うには少しつらそうな感もありますが、小〜中規模では問題ないのではないでしょうか。

終わりに

次回開催予定について尋ねてみたところ、1〜2月ごろに#1を行いたいと仰ってました。
また、今回のハンズオン内容の再演も春頃(?)に行われるようです。

講師を務めてくださった@ariarijpさん、@kakakakakkuさん、ありがとうございました!