社内もくもく会でRedashハンズオンをやった話

はじめに

yoshitaku_jpです。

社内でもくもく会を開催してみました。何を取り扱うか1つ決めておこう!となったときに、

  1. BI製品を扱っている会社なのでBI製品が良い
  2. ちゃんと資料が作成されているものがいい

と言う話が上がり、@ariarijpさんと@kakakakakkuさんが作成・講師をしてくださったRedashハンズオンを思い出しました。そして、今回はこれを社内メンバ数人でもくもく作業してみることにしました!自分はRedashハンズオン参加したこともあり、今回の社内もくもく会では講師・サポーターの立ち回りで動きました。

資料に関しては最高のものなので、再度メンバーを増やして開催する際や、別の方がやる際に参考になればとメンバが詰まったところを記載しておきます。

実際の作業で詰まったところ

Windows端末にdockerをインストールすることに手こずる

RedashハンズオンはDockerを使って作業を進めていきます。今回集まってくれた方の中には、Dockerがインストールされていない人もいたので、windows端末にDockerをインストールする作業からはじめました。「Dockerってどんなもの?」という質問も出ましたので、技術書典で購入した「マンガでわかるDocker」を読んでもらったりしてイメージを掴んでもらいました。(「他の仮想環境と技術的にどう違うのか」という質問も出たので、これはいつかまとめてちゃんと説明できるようにしておきます………)

Redashハンズオンの部分ではないのですが、一番詰まった点はwindows端末にDockerをインストールする点でした。Virtualizationが有効になっていなかったりで、BIOSをいじったりしました。キャプチャがないので追記します。
[Docker] Docker For Windowsをセットアップしてみた (Docker初心者向け)

docker-compose upがうまくいかない

docker-compose upした後に、Redashがうまく立ち上がらないことがありました。。(自分はWindows環境ではないのでエラーログのキャプチャがないのですが、後で共有してもらい貼っておきます。)原因はホスト側の端末でポート80を既に使っているために起こったもののようです。普段から開発している端末でハンズオンをおこなったので、まっさらなWindows端末でやっても同じことが起きるのでしょうか…調査が必要かも?またハンズオンを開催する際に同じことが起きるか見ておきます。今回は2/2人の確率で起きてしまったので、Windowsの方は注意が必要だと思います。

解決方法としては、docker-composeファイルのnginxのportsの”80:80″を”8081:80″にして、再度docker-compose upを叩きます。

# This is an example configuration for Docker Compose. Make sure to atleast update
# the cookie secret & postgres database password.
#
# Some other recommendations:
# 1. To persist Postgres data, assign it a volume host location.
# 2. Split the worker service to adhoc workers and scheduled queries workers.
version: '2'
services:
  server:
    image: redash/redash:4.0.1.b4038
    command: server
    depends_on:
      - postgres
      - redis
    ports:
      - "5000:5000"
    environment:
      PYTHONUNBUFFERED: 0
      REDASH_LOG_LEVEL: "INFO"
      REDASH_REDIS_URL: "redis://redis:6379/0"
      REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"
      REDASH_COOKIE_SECRET: veryverysecret
      REDASH_WEB_WORKERS: 4
  worker:
    image: redash/redash:4.0.1.b4038
    command: scheduler
    environment:
      PYTHONUNBUFFERED: 0
      REDASH_LOG_LEVEL: "INFO"
      REDASH_REDIS_URL: "redis://redis:6379/0"
      REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"
      QUEUES: "queries,scheduled_queries,celery"
      WORKERS_COUNT: 2
      REDASH_HOST: "http://localhost"
  redis:
    image: redis:3.0-alpine
  postgres:
    image: postgres:9.5.6-alpine
    # volumes:
    #   - /opt/postgres-data:/var/lib/postgresql/data
  nginx:
    image: redash/nginx:latest
    ports:
      #- "80:80"                            ←ここを変えます
      - "8081:80"                          #←これに変えます
    depends_on:
      - server
    links:
      - server:redash
  mysql:
    image: kakakakakku/mysql-57-world-database
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
      TZ: Japan

うまく起動することができたら資料に記載にあるhttp://localhostではなく、http://localhost:8081をブラウザでアクセスすると、Redashのログイン画面に行くことができました。

データソース設定が反映されない

RedashからMysqlのデータソースに接続できるように、設定をおこないます。しかし、画像のように右下にSuccessを緑で何回も表示されても、データソースにMysqlが表示されない事象がありました。

画像はhttps://github.com/kakakakakku/redash-hands-on/blob/master/images/data_source.pngより

原因はIEで動かしていたことでした。Chromeで再度Redashにアクセスしたところ大量に保存されたMysqlデータソースが発見されました(笑)。業務アプリケーションをIEで動かすことが多く、今回もRedashをIEで動かしていたようです。
Redashの公式サイトを確認したところ「We recommend using Chrome or Firefox.」という記載があったので、同様の事象があったときはどのブラウザを使っているか確認する必要、もしくは推奨どおりに「Chrome or Firefox」を使うことを最初にアナウンスしておくのがいいかと思います。

参考:https://redash.io/help/faq/general/

Browsers Redash Works Best
On We recommend using Chrome or Firefox.
If you encounter any issues that are browser specific, please let us know.

まとめ

今回は社内もくもく会でRedashのハンズオンをおこないました。
個人的に良かった点は3つほどあります。
1. 講師・サポーターの動きが学べた
2. 自分の知識整理になった
3. 社内でのコミュニケーションが生まれた

もくもく会なので、もくもく別の作業する人もいましたし、提案したRedashのハンズオンに参加していただけたりもして良かったです。
自分としては、社内なので圧倒的ホーム感の中でしたが、講師・サポーターの動きが学べて良かったです!!もっと他の人の学びやサポートに貢献していきたいと思いました。

質問をされたことによって、自分の知識の整理にもなった点も非常に良かったです!!

もくもく会が終わった後に飲み会をしましたが、その場でも活発にコミュニケーションが生まれて良かったです。とあるアプリケーションを使うときにリレーショナルデータベースとNoSQLどちらを使うべきかとか、自分が学んだ知識をすぐ活かせることができた点も印象に残っています。

NoSQLの基礎知識を読んだ

以上です!

NoSQL キーバリュー型のまとめ

はじめに

yoshitaku_jpです。

NoSQLの基礎知識について読んでいます。

NoSQLの基礎知識を読んだ


今回はキーバリュー型についてまとめておきます。

キーバリュー型

キーバリュー型はデータモデルがシンプルです。キーとバリューしかないです。このセットをデータとして書き込み、保存しておきます。データを呼び出すときはキーを指定して、バリューを取り出します。キーには文字列かバイト配列、バリューにはバイナリデータを持ちます。

NoSQLはデータが大きくなったときの対策としてはスケールアウトが適しています。サーバのスペックを良くするスケールアップではなく、サーバの数を増やしてく方法です。リレーショナルデータベースよりも簡単にスケールアウトができる点が、キーバリュー型の利点です。リレーショナルデータベースはデータの関係性を厳密に扱うので、他のテーブルとの整合性をとるために排他制御をおこなったり、テーブル定義を変更する際の待受処理を別に追加するケースもあります。複数のサーバがネットワーク越しに、それぞれのデータの関係性を維持することはまったくもって簡単ではないことです。

それに対して、キーバリュー型はキーを指定するだけでバリューがわかるので、データの関係性を維持する必要がないです。関係性を維持する必要が無いということはサーバがどれだけ増えても、複数のサーバにデータを分割することが出来ます。

キーバリュー型でデータを分割するときに簡単な方法は、「シャーディング」です。キー1をサーバAに、キー2をサーバBに分割して格納することです。
– メリット
– 簡単なこと
– デメリット
– サーバがダウンしたらキーとバリューを両方失うことになる

デメリットに対する対策は、キーとバリューを複数のサーバに複製することがある。しかし、複数のキーとバリューがあると、すべてのバリューが更新されているかどうかがわからないので、サーバAにあるキー1とサーバBにあるキー1で違うバリューを持つ可能性がある。
このデメリットを解消するソリューションがないNoSQLだから単独のサーバで運用しているものや、一方でBigtableやDynamoといった大規模分散型のNoSQLはデメリットを解消するような実装を持っている。

まとめ

  • キーバリュー型について学んだ
  • データモデルがキーとバリューで構成されていてシンプル
  • データが大きくなったらスケールアウトをしよう
  • データを分割するときに簡単なのはシャーディング
    • メリットは簡単なこと
    • デメリットはサーバがダウンするとキーとバリューの両方を失うことになる

NoSQLの基礎知識を読んだ

はじめに

yoshitaku_jpです。

社内の有志で何か製品を作ってみよう!ということで動いています。そこでNoSQLの話になって、「自分NoSQL触ったこと無いんだよなぁ」と思ったので、その部分の担当に立候補しました。データベースと言ったらリレーショナルデータベースの方しか思い浮かばないレベルですので、入門的な本をカカカカックさんに紹介していただき「NoSQLの基礎知識」を読んでいます。NoSQLの製品名を少し知っているだけの自分だからこそ書けるものかと思うのでまとめメモとして残していきます。

なぜNoSQLが求められるか

ビッグデータの時代にリレーショナルデータベースが対応できなくなってきた背景があるようです。ビッグデータを扱う際に求められることは、3つのVと呼ばれています。「Volume(膨大な量)」「Velocity(速さ)」「Variety(多種多様)」です。

Volume(膨大な量)

膨大な量というのは、一つ一つのサイズが大きいものではなく、小さなデータの集まりのことです。ツイッターで個人が呟いたりするのは微々たるものでも、世界中の人が呟いたらすごい数になります。このような小さなデータが膨大に集まり、大きなデータとなることをビッグデータと呼び、そのビッグデータを扱うことをNoSQLには求められています。

Velocity(速さ)

ビッグデータに対応するためには、素早く処理する必要があります。
想像できないほどですが、

「Twitterには日次12テラバイトものデータが発生し、仮に、ハードディスクの書き込み速度が毎秒約80メガバイトのマシンを1台だけ使うとしたら、全てのデータを格納するだけでも約42時間(12TB÷80MB)かかることになる」
と書かれています。1台のマシンで処理できることも限られていますので、同時並行して処理する環境が求められたり、高速に処理するソフトウェア技術が求められます。

Variety(多種多様)

ビッグデータは形が決まりきっているデータの集まりとは限りません。データ同士の構造が複雑化しています。それらを均一に揃えて利用していく構造化は困難となっています。そのため、この複雑な構造を持ったデータをそのまま格納し利用していくことがNoSQLには求められています。

まとめると、

ビッグデータへの対応は、「膨大かつ多種多様で激しく変化するデータの塊を、制限なしに保存しつつ、迅速に処理すること」
と書かれています。

NoSQLの種類は100種類以上ある

  • Oracle
  • MySQL
  • PostgreSQL
  • Microsoft SQL Server
  • MariaDB
  • Amazon Aurora
    この一覧は、AWSのAmazon RDSに載っているものです。非常に一般的な6種類です。それに比べてNoSQLは100種類以上存在しているようです。なぜこんなに多くのNoSQLが存在しているかというと、NoSQLが「Not Only SQL」という、SQLを使うリレーショナルデータベースに限らない技術を使っているものの総称だからです。NoSQLがSQLを使わないものをまとめた言葉だから、結果的に多くなってしまっているんですね。ということでNoSQLは細かく見ていけば、利用シーンを限定的にしたものの集まりです。豊富な機能を備えたリレーショナルデータベースとは違います。そんなNoSQLも大きく分類すると4種類に分類できます。

NoSQLは4つに分類することができる

NoSQLも大きく4つに分類することが出来ます。「キーバリュー型」「カラム思考型」「ドキュメント指向型」「グラフ型」です。
– キーバリュー型
– カラム思考型
– ドキュメント指向型
– グラフ型

細かく見ていきます。

キーバリュー型

  • キーとバリューを対にしたデータモデル
  • リレーショナルデータベースよりも処理の負荷が小さい
    • 結果的に処理の遅延が発生しにくいので、複数サーバへの分散配置やスケールアウトが簡単にできる
      知っていた製品名は「Amazon Dynamo」「Redis」です
      文章中に紹介されていた製品名は「Dynamo」「Voldemort」「Riak」「Hibari」「Redis」「Scalaris」「Tokyo Cabibet/Tyrant」です

https://yoshitaku.net/2018/05/18/742/

カラム思考型

  • ひとつの行キーと複数のカラムが対になり、カラムの追加を動的にすることができる。
    知っていた製品名は「cassandra」「cloudata」です
    文章中に紹介されていた製品名は「Bigtable」「Cassandra」「HBase」「Hypertable」です

ドキュメント指向型

  • プログラミング言語で記述された形でデータを管理
  • ドキュメントの内容をクエリ化することもできる
    知っていた製品名は「MongoDB」です
    文章中に紹介されていた製品名は「CouchDB」「MongoDB」です

グラフ型

  • データとデータのつながりを管理する。
    • その関係性をグラフ化することができる
      知っていた製品名は…ありませんでした。
      文章中に紹介されていた製品名は「InfiniteGraph」「Neo4j」です。

まとめ

今回はNoSQLの基礎知識の1,2章を読み内容をまとめてみました。
次回からは、キーバリュー型・カラム思考型・ドキュメント指向型・グラフ型を深く掘り下げていきます。

RPAだけじゃない?! / RPA勉強&LT会!RPALT vol2に参加してきた

はじめに

yoshitaku_jpです。

1回目に引き続き、RPA勉強&LT会!RPALT vol2@ウイングアーク1stに行ってきました。

前回のレポートはこちら
自動化しよう! / RPA勉強&LT会!RPALT vol1に参加してきた

自動化しよう! / RPA勉強&LT会!RPALT vol1に参加してきた

connpassコミュニティの人数も500人近くに増えていてびっくりしました。参加者も233人で、前回から100人近く増えています。ほぼ開始時刻の19時30分に到着したのですが、席が空いていないぐらい満員で注目度の高さが伺えます。今回は大変残念ながらプレゼン資料が見えにくい位置だったので、サラッと振り返ります!

チャラ電さんのお話

素敵なステッカーありがとうございます。

10分間 RPA概論~導入開発編~ / 一戸さん

  • 自動化するためにプログラミングがいらないと言われることが多いが結局はプログラミングなところが多い。
    • 言語は何が使われているか気になったので調べてみる。
  • 即時性が高かったり、リカバリが出来ない業務(クリティカルな業務)は原則としてRPA化は向いていない。
  • 人がやっていることを置き換えているだけなので、人がやっていること以上のことは出来ない!!
  • 内製の理想はユーザですべてやることだけど、コンサルやベンダが入ることはまだ避けられない!
  • RPA開発のスキルはシステムだけではなく、ユーザの業務がすべて見れるようなスキルが求められている。
  • 例外設計や、運用などが今後の課題

感想

懇親会で参加者から聞いたのですが、プログラミング言語はVB.NETが使われているようですね。RPA!自動化!とは言われていますが、やはりプログラミングとなかなか切り離せない世界のよう。ガリガリ書けなくても、読めるぐらいの知識は必要そうです。「即時性が高かったり、リカバリが出来ない業務(クリティカルな業務)は原則としてRPA化は向いていない。」「人がやっていることを置き換えているだけなので、人がやっていること以上のことは出来ない!!」この2つは大きい部分な気がします。この部分を忘れて開発をし始めるとどうなることやら…

<デモ>ロボ部長メール(部下編) / 青野さん

  • RPAチームの心の声
    • スクレイピングしてバッチ処理で回したほうが早いのでは?
    • windowsのactiveXのバージョンが違うことによってエラーが吐かれた
    • 意外と止まる。
      • 金額のところに、カンマが入ってる入ってないでエラーになった
      • 文字数オーバー
      • VPN切れる
    • 結局ユーザ業務に詳しくないと開発が辛い
  • 部長メールのデモ!

感想

RPAに引きづられると、スクレイピングしてバッチ処理で回したほうが早いのでは?のような目的と手段を見誤るようなケースがあるので、RPAに適している業務なのかの検討はすごく重要だと思いました。RPA開発をする際は、ユーザ業務の理解がシステム開発をする以上に大切ですね。この話は一戸さんのときにも語られていました。例外処理の考え方はが実際に動かしてみないとわからないことも多そうですね。ネットワークが切れた際の処理や、はたまた遅かったりすることを考え始めただけで、パターンが多くなります。

LT

OCRサービス「Tegaki」を利用した手書きデータ入力の自動化の話し / 亀井 美佳@セゾン情報システムズ さん

UiPathの構築ポイント 〜具体的な例を用いて開発のポイント教えます〜 / 牟田 佳奈子@株式会社Arinosさん

クラウドRPA提供企業の実演動画+リリースして8ヶ月の気付き / 嶋田 光敏@BizteX さん

<資料なし>

headless chromeでRPA(?) / connpassイベント管理者の苦悩を改善するための自動化話 / のびすけ@dotstudio,inc.

+AIでRPAによる業務の自動化範囲を拡大 / 高木 章光@ブレインズコンサルティングさん

TwilioでRPAしちゃうぞ! / 高橋 克己@Twilio/KDDIウェブコミュニケーションズさん

RPA、およびIoTの連携による物理的ネットワークセキュリティの考察 / 井手 拓人@RPA Community さん

感想

どれも面白いLTでした!やはりRPAということで、実際に動いているデモを見せてもらうことが多かったです。あとはOCRを使った物が多かったですね。RPAとOCRは相性が良いのでしょうか?どのようなモノ・コトをRPA開発しているのかアンケートも見てみたいですね。自分も自社内でOCRのプロダクトを作っていて、RPAとの連携を模索しているので大変興味を持って聞けました。亀井さんのお話の中にあった「Tegaki」はぜひ使ってみようと思います。
RPAを考えていく際にエラーは必ず発生するものと考えると仕切りに言っているのが気になりました。自分も前回の勉強会が終わった後に、勤務表への登録をSeleniumとPythonを使って自動化してみたので、これからはうまく動かずにエラーが起こった際どうしていくかを考えながら実装してみようと思います。
自分の中でのRPAのイメージは画面上での操作を記憶させて実行するものだと思っていましたが、簡単なプログラムを書くことも多いそうです。それこそSeleniumとPythonを使って実現するような感じでしょうか。ユーザさんにとってまだまだハードルが高く感じられるところに、開発者としては関われることが多く残っているのかなと感じました。

懇親会では実際に案件で携わっている方をお話する機会がありましたが、実際に動いているものをお客さんに見せて感動して貰えるとすごく嬉しいと言っているのが印象的でした。多くの価値を生み出せる方がやっている無駄な作業をRPAすることによって、更に価値を生み出していけることに貢献できることが良かったみたいです。他には、RPAとしてお話を聞きに行っても、青野さんの「スクレイピングしてバッチ処理で回したほうが早いのでは?」ようにRPAじゃないほうがいいことも多いみたいです。やはりお客さんの業務理解・キャッチアップが速くないといけないんでしょうね。

RPAトレーニング講座が始まる

実践的なRPA Trainingが始まるようです。RPAトレーニング講座「UiPath入門編」は全4回の1回目みたいです。少人数で多くのことが学べそうなので、実案件で困っている人はいいかもしれませんね!

集合写真と登壇者の方

ありがとうございましたー!

macからラズベリーパイのデスクトップ画面を操作するためにVNCを入れた

はじめに

yoshitaku_jpです。

macからラズベリーパイのデスクトップ環境にアクセスしたくて、vncを設定しました。
ラズベリーパイのデフォルトで入っているRealVNCを使う場合は、mac側にソフトウェアを入れないといけないようで、tightvncserverを使うことにしました。

tightvncserverのインストール

sudo apt-get install tightvncserver

実行

ラズベリーパイにsshなどでログインし、vncserverコマンドを実行します。
初回はパスワードを聞かれるので設定し、メモをしておきます。

pi@raspberrypi:~ $ tightvncserver

New 'X' desktop is raspberrypi:5

Starting applications specified in /etc/X11/Xvnc-session
Log file is /home/pi/.vnc/raspberrypi:5.log

のようになっていれば成功です。

mac側に戻って、
Finder-移動-サーバに接続をクリックします。
vnc://xxx.xxx.xxx.xxx:590y
xxxの部分はラズベリーパイのIPアドレスを
yの部分はNew 'X' desktop is raspberrypi:5の5の部分の数字を入れて接続をします。(大抵は1番です。今回は何回もやり直したので5番になっています。)

完了

デスクトップ画面が開けていれば成功です。


補足-自動起動の設定

vncserverをsshでログインし、起動し、デスクトップ環境へ…というのがめんどくさい人には自動起動設定しておくことをオススメします。

cd /etc/init.d
sudo nano vncboot
#! /bin/sh
# /etc/init.d/vncboot

### BEGIN INIT INFO
# Provides: vncboot
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start VNC Server at boot time
# Description: Start VNC Server at boot time.
### END INIT INFO

USER=root
HOME=/root

export USER HOME

case "$1" in
 start)
   /usr/bin/vncserver :1 -geometry 1280x800 -depth 24
   echo "Starting VNC Server."
   ;;

 stop)
   /usr/bin/vncserver -kill :1
   echo "VNC Server Has been stoped."
   ;;

 *)
   echo "Usage: /etc/init.d/vncboot {start|stop}"
   exit 1
   ;;
esac

exit 0
sudo chown root.root vncboot
sudo chmod +x vncboot
sudo update-rc.d vncboot defaults
sudo reboot

で、VNCが起動しないと…

様々な記事を参考にしましたが、スクリプト内の/usr/bin/vncserver/usr/bin/tightvncserverに変えたら自動的にVNCが動くようになりました。
自分がいろんなソフト入れてるから邪魔しちゃってるのか、vncが変わったのか…
もう一回ラズベリーパイのOSを入れ直すタイミングが合ったら検証してみます。

#! /bin/sh
# /etc/init.d/vncboot

### BEGIN INIT INFO
# Provides: vncboot
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start VNC Server at boot time
# Description: Start VNC Server at boot time.
### END INIT INFO

USER=root
HOME=/root

export USER HOME

case "$1" in
 start)
   /usr/bin/tightvncserver :1 -geometry 1280x800 -depth 24
   echo "Starting VNC Server."
   ;;

 stop)
   /usr/bin/tightvncserver -kill :1
   echo "VNC Server Has been stoped."
   ;;

 *)
   echo "Usage: /etc/init.d/vncboot {start|stop}"
   exit 1
   ;;
esac

exit 0