UZABASE Tech Blog

株式会社ユーザベースの技術チームブログです。 主に週次の持ち回りLTやセミナー・イベント情報について書きます。

ユーザベースで社内ハッカソンを初開催しました

f:id:uzabase:20180217001643p:plain

はじめに

ryoqunこと小野寺です。突然ですが、うだるような熱狂的なハック、最近してますか?僕らのそんな刺激的で情熱的な一夜限りの思い出を今日はレポートしたいと思います。

ユーザベースでは2017年12月15日に社内ハッカソンを開催しました。初開催にも関わらずとても楽しかったので、その取り組みについて紹介したいと思います。

今回の社内ハッカソンがユーザベースでの栄えある1回目の開催です。大好評に終わり、こういったエンジニアの社内イベントは継続的に開催していくことになりました。

聞くだけに終わらない「Tech Meeting」にするために

「エンジニアみんなが等しく能動的に技術に向き合う時間にしたい」

この思いを実現したいがために、板倉というエンジニアから今回のハッカソンは立案され、開催されました。その根底には、週次のエンジニア全体ミーティング(いわゆるTech Meeting)の本来の意義を、180度違う角度から解決したいという熱意が板倉にあったためでした。

これまでの弊社のTech Meetingは持ち回りで担当者が何らかのテーマで発表をするというものです。

そこには、「話す」、「聞く」という参加者の二分があり、「聞く」側の中ではさらに、「質問する」、「聞いているだけ」というさらなる二分があり、 Tech Meetingに参加しているエンジニア各人の時間の濃さにムラがあるのが課題でした。ユーザベースグループという組織において、それは望むところではなく、そこに強い問題意識を持ったのが彼でした。

弊社におけるTech Meetingの意義とは、「技術」を軸にエンジニア同士が交流すること。だからこそ、あえてTech 「Meeting」でなくてもよいのでは?その問題提起から、四半期分のTech Meetingの時間をまとめ、1日まるまる時間を確保し社内ハッカソンを開催することになりました。

ちなみにそのような大胆な改革であっても、(あるいは、ならばこそ)すんなり挑戦よいとなりました。というのも、ユーザベースの7つのルールに「自由主義で行こう」や「迷ったら挑戦」とあり、基本的に社員のWillが尊重されるからです。

そして同じような問題意識に共感し、ハッカソンを運営したいと手を上げたメンバーを加え、板倉を中心に数名の運営チームが組成されました。

自由と挑戦を念頭に、ユーザベースらしいハッカソンを。

まず、ハッカソンのお題はありません。つまり開発テーマは完全に自由です。作るものの制限はなく何でもOKでした。この背景には、できるだけレギュレーションとして制約を設けずに運営側の思いとして個々人が好きな技術に能動的に触れてほしいというのがあったためです。

結果、業務に関係あるものから、関係無いものまで、具体的にはゲームからチャットボットに至るまで、実に色々なものが作られました。

さらに、チーム分けはランダムに極力「混ざる」ようになりました。ユーザベースが大きくなるのにつれ事業部間のエンジニアの距離が遠のいてしまうのを解消したいという運営チームの思いから、有志がなんとなくいつも通りにまとまるのではなく、基本的には運営チームによって決めました。ただ、参加者の志向性をまったく考慮しないわけではなく、興味ある技術や趣味を参考とするためにアンケートを取りました。

そして、当然のごとく、最終発表後には表彰と賞品の贈呈「アリ」とのことでみんなは俄然やる気がでます。

ハッカソンの日程は、告知から打ち上げまで、大きくは次のように進んでいきました。

f:id:uzabase:20180217001028p:plain

  • 10/2: ハッカソン開催の発表
  • 10/18: ハッカソンのチーム分け発表
  • 10/30: チーム別中間発表(チームごとの取り組む開発内容の発表)
  • 12/14: ハッカソン開催宣言(18:00〜)
  • 12/15: チーム別最終発表&表彰&打ち上げ(17:00〜)

では、時系列順に足早になりますが、写真を織り交ぜつつ説明していきたいと思います!

10/2: まさかのハッカソン開催の告知

f:id:ryoqun:20180131212300p:plain

今日も代わり映えの無いTech Meetingの発表の最後に突如出たこの素っ気ないスライド一枚から全ては始まりました。

まず、突然に、4QではTech Meetingの代わりにハッカソンをするという発表がありました。当然、発表直後はざわつきました。

ともかくも、Tech Meetingの時間枠を集めてハッカソンにしてしまうという発想が非常に新鮮で、みんなの不安と期待と野望(?)の中で、ここから物事は動き出しました。

10/18: どきどきのチーム発表!

f:id:ryoqun:20180131094856j:plain

まずはともかく、ハッカソンをやるにはチーム分けから始まります。2〜6人のチームが合計が15チームができ、ユーザベースグループのエンジニアが総動員した結果、55名とかなりの大規模です!

前述の通り、チームの構成はなるべく事業をまたぐよう意識されました。この工夫にはエンジニアの交流を増やしたい狙いがありました。ただ、個人の希望も考慮するため、ハッカソン告知後に興味のある技術や趣味のアンケートは参考のために事前に実施されました。そして、運営メンバーも各チームのメンバーとして実際のハッカソンに参加しました。これもまた運営チームの思いの現れです。つまりは、Tech Meetingでの「聞く側」と「話す側」の二分構造と同じような「運営側」と「参加側」の二分構造の発生を避けるためでした。

チーム分け後、各チームのメンバーは基本的には初対面です。自己紹介したり、キックオフランチに行くチームもありつつ、各チームは早急に何を作るのかを中間発表に向けて決めなければなりません。もちろんチームの各メンバーの持ち味を活かしつつ!

10/30: 夢が膨らむチーム別中間発表!

チーム発表後、お互いのチームが何を作るかの噂が流れたりして、そわそわしつつ、ついにこの日に各チームが発表しお互いが何を作るのかが明らかになりました。

前述の通り、お題は完全自由で実に多彩な案が出ました。Slackのボットから簡単なWebサービス、はたまたゲーム、音声認識、IoTなどなど、やはり最新技術を取り入れたチームが大半です。

どのチームの企画もチームの特色があり、ひねったアイディアばかりで新規性や革新性があり、発表内容を聞いているだけでワクワクしました。

そして、この中間発表以降、本気で賞を取りにいこうとしたチームは先行して開発に着手し始めました。

12/14: 前夜祭的な開催宣言!

f:id:ryoqun:20180131134910j:plain

準備したチームがありつつも、ついにハッカソンの開催が宣言されました!

f:id:ryoqun:20180131213222j:plain

ちなみにこんな感じでお祭り感UP!ということで趣ある方法で成果発表の順番は決められました。

がっつりハック!各チームの開発風景

f:id:ryoqun:20180131213846j:plainf:id:ryoqun:20180131212926j:plainf:id:ryoqun:20180131213111j:plain

みんなが楽しそうに各チームが1つの目標の元で開発しています。最新技術や、技術を使っての誰かために問題解決が好きなんだなと思えた瞬間でした。

ぎりぎりまで粘った上での成果発表!

f:id:ryoqun:20180131213659j:plain f:id:ryoqun:20180131214332j:plain

ハッカソンなので完璧さは求められません。大事なのは、とりあえず動くものを作ること。その心意気で、みんな発表開始直前の直前まで開発していましたが、時間は無情で成果発表の時間となりました。

今回のハッカソンのテーマは「楽しく」なので、最後まで追い込んでまで必死に開発したご褒美というわけで、ビール片手の乾杯から成果発表はスタートしました。

各チームの発表持ち時間は5分で、うまく動いて歓声があがったり、ツッコミが入ったりしながらもテンポよく和気あいあいと進んでいきます。やはりデモを披露するチームが多かったです。

そして、成果発表後、交流の時間が設けられ、気になるチームのところに行って話したり、デモを試したり、逆に興味を持ってくれたエンジニアにデモを見せたりしました。

そして、各賞にふさしいと思うチームへの投票も終え、ついに、どきどきの表彰タイムです!果たして自分のチームは選ばれたのでしょうか??

表彰!

泣いても笑っても結果が全て。以下の通りで各チームがそれぞれ受賞しました!!

今回の賞は合計4つでした。エンジニアみんなが投票して選ぶ「Good Idea賞」、「Tech賞」、「最優秀賞」の3つと、サプライズでユーザベースグループのCTOの竹内さんからの「特別賞」がありました。

「Good Idea賞」

f:id:ryoqun:20180131135706j:plain

まず、「Good Idea賞」に輝いたのは、「Slaxフレンズ制作員会」というチームで、Slackの中でUnixコマンドの思想に則ったコマンドライン環境を提供するという一風変わったBotを作りました。ちょっと補足すると例えばSlack上でtail -n100 @ryoqun | grep "ハッカソン"と入力すると、ある特定の人の直近100件の発言から特定ワードで絞り込んで表示するというBotです。

「Tech賞」

f:id:ryoqun:20180131140214j:plain

次に、「Tech賞」に輝いたのは、「チームPon!」というチームで、ARと体を動かすというのを組み合わせたホッケーのようなゲームを作っていました。対戦もでき、スマホがコントローラー代わりになり、ブラウザからゲーム状況も見えたりとARKitを使った本格的なARと同時にゲームとしての完成度も十分でした。

「最優秀賞」

f:id:uzabase:20180207211449j:plain

では、栄えある「最優秀賞」に輝いたのは、「もんめ」というチームで、社内ポータルをリニューアルさせました。なんといっても開発成果のインパクトが一番でした。ユーザベースでは社内ポータルとしてCrowiを使い始めているのですが、それをフロントエンドを中心にデザイン含め、大規模にリニューアルしました。Reactを使って書き換え、オープンソースも予定しているとのことで期待も高まります。

「CTO特別賞」

最後に、サプライズだった「CTO特別賞」に輝いたのは2チームでした。

1チーム目は、「私立恵比寿中学水樹奈々がかり」というチームで、Google Homeで、アイドルのライブイベント当日の移動等の準備に便利な音声操作のツールを作りました。

2チーム目は、「UBHome」というチームで、Raspberry Piと各種音声認識や発声APIを使ったIoT的な音声受付システムを作りました。

無事に終わり、金曜夜、あとはやることといったら…

そして、成果発表開始時よりアルコール解禁になっていたのもあり、ウォーミングアップ(?)も済ませ、睡眠不足のテンションで意気揚々に、有志で打ち上げへと恵比寿の居酒屋に繰り出していくのでした〜。

「(ハッカソンを通して)仲良くなれた。楽しかった」

開催後のアンケートから抜粋すると以下のようなものがありました。

「運営お疲れさまでした!最後の発表会で予想を遥かに越えて、けっこうみんなが真面目に取り組み、良いものができたと思います!」

「普段業務で会話することがない人とも、短期間ではあったものの1つの目標に向かって協力できたことで仲良くなれたな、と思いました。」

「久しぶりにコーディングに集中しすぎて発表の時に疲れましたがめっちゃくちゃ楽しかった!!」

ありきたりかもですが、こういう反応こそを引き出せたのは、その当たり前を多くの苦労で実現した運営チームの尽力あってのことだと思います。

「みんなが楽しめたならOK!(運営は大変だった…)

開催後日、最後に板倉より以下のメッセージがありました。

「告知時に話をしましたが、今回のハッカソンはみんなが能動的に参加できるように考えたものです。撮影した写真の中では、ハッカソン当日はみなさん笑顔が多く、良い時間が過ごせたのではないかと思います。上記の目的が少しは達成できていたのであれば良かったです!」

という形で初開催のハッカソンは無事に幕を閉じました。

また、最初から完璧な運営できたわけではなく、反省として、「もっとお祭り感を運営チーム働きかけて作りだせたのではないか」、「チーム間の取り組みへの温度感のムラをもっと埋められないか」、「受賞したいと思えるような賞品にできたのでないか」などがありました。

まとめ

ユーザベースでは、「経済情報で世界をかえる」というミッションの実現のため、エンジニアが共に力を合わせ自由闊達で働ける環境を作ろうとしています。

ユーザベースはグループとして、ただそのミッションために存在し、そのミッションで束ねられた組織の団結力は非常に重要であると考えています。そのためにも、エンジニアという1つの職能という横串の切り口で、今回のようなレクレーションイベントを通し、結束力を高められたのは本当によかったです。

さらに朗報で、今回の社内エンジニアイベントに続き、次は社内ISUCONを開催しようということが決定しています。

最後になりますが、ユーザベースでは、絶賛エンジニアを大募集中なので興味ある方は是非とも応募してください!

【k8s合宿】 Kubernetesのログ分析環境を作る

こんにちは、SPEEDAのSREチームでエンジニアをしている阿南です。SPEEDAのSREチームでは、昨年末kubernetesについて理解を深めるために合宿を行いました。やり方はA〜Cの3チームに分けて、それぞれのチームでkubernetesに関することを調査、構築するという形式で、今回はAチームが実際にやってみた内容についてブログを書きたいと思います。(それぞれのチームでかなりボリュームがあるので、複数回に渡って連載的な形でお届けしたいと思います。) Aチームでは、kubernetesを本番環境に投入するにあたり、ログ収集周りをあまり調査できてないなと感じ、GCP上に環境を作ってみることにしました。

構築する環境

f:id:uzabase:20180115151549p:plain

GKEでKubernetesクラスターを構築し、その上にwordpress(Apache) + MySQLコンテナを稼働させました。ログ収集と言っても、kubernetesクラスター自体のログとその上で稼働するコンテナのログでは取得する設定も若干違ってきますので、今回はコンテナのログを収集する環境を作りました。 またポイントとして、GKEの公式DocumentではStackdriverにログを送ってBigQueryにエクスポートするという構成が紹介されているのですが、BigQueryに直接送る構成はあまり情報がなく、SPEEDAのコアな部分はオンプレ環境で運用しているため、BigQueryに直接送る構成にしました。

構築手順

ログを収集するという単純な環境ですが、意外と設定項目が多いです。手順を一つずつまとめるとかなり分量があるため、設定内容も含めてgithubに手順をまとめました。

github.com

1から構築してみたいという方はぜひご参考にしてください。 本ブログ内では、私が重要だと思った点や注意点のみ記載したいと思います。

クラスター構築

GKEは下記コマンドのみでkubernetesのクラスターを構築することができます。

$ gcloud container clusters create sample-cluster

デフォルトではGCEのインスタンスが3台起動し、そのVMを利用してkubernetesのclusterが作成されます。

wordpress + MySQL構築

続いて、wordpress + MySQL です。こちらについては、GCPの公式ページのステップ2〜5を参考にしました。wordpressのコンテンツファイルやDBのデータを永続化するために、 volumes で外部ディスクを指定し、containersvolumeMounts でマウント設定しています。

gist.github.com

Fluentdイメージの作成

利用するイメージは、GCPのリポジトリを参考にイメージを作成すればOKです。ポイントとして今回はbigqueryに直接ログをアップロードするため、gemfileで、fluentdのバージョンをv0.14に変更し、fluent-plugin-bigqueryを追記しています。このgemfileを保存して、docker buildしてください。 fluentd.conf の設定は全てConfigMapで記載します。

gist.github.com

ConfigMap設定

ConfigMapは、設定情報(環境変数やファイル)を定義できるkubernetesの機能です。これを使うと、kubernetes上でコンテナを実行した際に、ConfigMapに設定した情報を読み取ってくれます。例えば、fluentdのイメージをDocker単体で実行した場合、configをホストマウントしたりしますよね。kubernetesだとホストが頻繁に変わる可能性もあるのでホストマウントするわけにもいきません。そのような場合に、ConfigMapを利用すればconfigをimageに含めなくてもよくなり、ノードが変更した時にも追従できるということでクラスターのノードを捨てやすくなると思います。

gist.github.com

実際のfluentdの設定についてはファイルを確認して頂ければと思いますが、注意点としてfluent-plugin-bigqueryの現在のバージョンでは inject セクションが追加されているようです。過去のブログ記事で設定にinjectがないものもあり、そのまま設定するとBigQueryのtimeだけnullになってしまうことになりますのでご注意を。

<inject>
    time_key "time"
    time_format "%s"
</inject>

DaemonSet設定

DaemonSetはクラスターの各ノードにコンテナをデーモンで動作させることができるkubernetesの機能です。コンテナのログは各ノードに出力されるようになっています。このDaemonSetを利用してfluentdを各ノードに稼働させ、各ノードのログを収集します。

gist.github.com

長いので、かなり省略していますが、 volumes で先ほど設定した configMap を指定し、 containersvolumeMounts に設定しています。これで、ConfigMapで定義したファイルをfluentdが起動時に読み込み、ログ収集ができるようになります。

f:id:uzabase:20180115173310p:plain

ちなみに、下記コマンドでwordpressのpodと同じノードで稼働しているfluentdのpodを確認し、shellを起動するとfluentdのログを見ることができます。うまくfluentdのログがアップロードできない等の場合は見てみるといいかもしれません。

$ kubectl get pods -o wide
NAME                         READY     STATUS    RESTARTS   AGE       IP           NODE
fluentd-gcp-v2.0-5t96f       1/1       Running   0          5h        10.52.2.9    gke-sample-cluster-default-pool-a7431f33-rqbs
fluentd-gcp-v2.0-j45c7       1/1       Running   0          13m       10.52.0.13   gke-sample-cluster-default-pool-a7431f33-4x57
fluentd-gcp-v2.0-wmv3h       1/1       Running   0          5h        10.52.1.10   gke-sample-cluster-default-pool-a7431f33-nv5h
mysql-3368603707-ng8pr       1/1       Running   0          6h        10.52.0.7    gke-sample-cluster-default-pool-a7431f33-4x57
wordpress-3479901767-tc9p6   1/1       Running   0          6h        10.52.0.8    gke-sample-cluster-default-pool-a7431f33-4x57

$ kubectl exec -it fluentd-gcp-v2.0-j45c7 /bin/sh
# tail -f /var/log/fluentd.log

最終的に、下記のようにアップロードされました。現状だと全てのコンテナログが同じテーブルにinsertされてしまいますので、この辺りは別途テーブルやfluentdを細かく設計した方が良さそうです。

f:id:uzabase:20180118112409p:plain

まとめ

ログをアップロードするために必要な設定を見ていきました。使ってる機能が意外と多いので、少し時間がかかりましたが、本番環境で運用するにはマストの機能ばかりかと思います。また、fluentdから直接BigQueryに送ることにより、マルチクラウドでも対応できるし、OutputをBigQueryから他サービスに変更(もしくは追加)することも簡単にできますので、シーンに応じて使い分けできると思います。結構つまづいたのがfluentdで、jsonログをparseし、特定のキーに対してさらに複雑な加工をしたい場合にちょうどいいプラグインが見つからなかったのでその辺りは調査、もしくは、自分でプラグインを作るのもありかなと思います。 次回以降で、データの可視化やkubernetesのメトリクス収集等も紹介していきますのでこちらも乞うご期待。

お知らせ

SREチームでは「No Challenge, No SRE, No SPEEDA」を掲げ、ユーザベースグループのミッションである「経済情報で、世界をかえる」の実現に向けて、日々業務に取り組んでいます。 興味を持ってくださった方はこちらをご確認ください。

クローズドな勉強会 SRE Lounge始動!

はじめまして、SPEEDA SREチームの久保です。

今回当社のSREチームとハートビーツ社が共同で、1/17(水)に他社を巻き込んで、SRE LoungeというクローズドなSRE勉強会を開催したので、シェアしたいと思います。

SREとは?

Site Reliability Engineeringの略で、日本語に訳すと、「サイト信頼性エンジニアリング」です。 簡単に説明しますと、IT Proの記事にありますように、

SREとはコーディングやソフトウエアエンジニアリングによって、ハードウエアを含めたシステム全体の性能や可用性、セキュリティを高める活動全般を指す方法論

を指します。

ユーザベースのSPEEDA SREチームとしては、
従来のようなDevとOpsに役割やプロセスが分かれており、それぞれのエンジニアが各々の役割だけにコミットする状態ではなく、ソフトウェアの設計、開発・構築、デプロイ、運用、改善といったソフトウェアの一連のライフサイクルのすべて(DevとOps全体)に焦点を当て、サイトの信頼性の向上にコミットするために、ソフトウェアエンジニアリングによってプロダクトの改善を行う。

と解釈し、プロダクト全体の改善に日々努めています。

SRE Loungeの開催背景・趣旨

O'ReillyのSRE本にもありますようにSREはGoogleのDevOpsであり、必ずしも各社にとっての最適解ではあるとは限りません。

また、SREチームを持つ企業各社によって、SREとしての取り組みも様々なのが現状です。 SREチームを構成するメンバーのエンジニアとしてのバックグラウンドも会社によって異なります。 ユーザベースのSPEEDA SREチームでは、ソフトウェアエンジニアとインフラエンジニアが1:1ですが、その比率は企業によって様々です。

そのため、既に各地で開催されているような一方向の講座形式の勉強会ではなく、 双方向に取り組みのシェアや課題の共有などができる、双方向のインタラクティブな場が必要と考え、今回SRE Loungeという名前で企画しました。

SRE Loungeのコアコンピタンス

  • 1回の勉強会で複数社のSRE取り組み事例を知ることができる
  • 少人数のクローズドな場にすることで、双方向なコミュニケーションが取りやすいこと(=質問がしやすく、参加者-発表者間で議論ができる場)

勉強会ゴール

  • SRE取り組み事例の共有(情報交換, 発信)
  • SREについて議論し、知見を深める

開催日時

1/17(水)19:00〜で、 ハートビーツ様のラウンジをお借りして開催しました。

ハートビーツ様の会場はとても素敵な場所でした。代表の藤崎さんのこだわりで作られたとのことです。羨ましい! f:id:hir023:20180122104731j:plain f:id:hir023:20180121203821j:plain

参加企業

コンテンツ概要

  1. 各社SRE関連の取り組み事例紹介&質疑応答 (各社20~25分)
  2. 意見交換会、ディスカッション(with ビール・ピザ) (30~40分)

コンテンツ

各社それぞれのSREの取り組み事例を知ることができ、非常に濃い時間でした。 簡単に各社の発表内容をシェアしたいと思います。

ハートビーツ社

  • happoというツールを独自で作成し、自動でNagiosのメトリクスを収集し、かつ自動でメトリクス設定するツールなども開発して監視している。
     参考:heartbeats.jp
  • トイルの削減方法としては、nagiosのアラートをslackに通知し、スレッド単位で対応している。

当日発表資料:https://speakerdeck.com/abnoumaru/sre-lounge-20180117



dely社

  • 障害対応訓練(dely Apollo Program)という、過去に発生した障害と同じ状況を生み出し、インフラエンジニア以外のエンジニアにその復旧作業に取り組んでもらう。復旧作業での作業をすべてメモし、なぜその作業を行ったかをヒアリングし、振り返るプログラムを実施している。

当日発表資料:https://www.slideshare.net/motonobufukao/dely-sre-principles



eureka社

  • AWS環境で、Packer × Ansible × Terraformで、プロビジョニング用のAMIを作成し、そのAMIベースでインスタンスを作成。一度起動したインスタンスには変更を加えない構成にしている。

当日発表資料:https://speakerdeck.com/takuya542/ji-sok-de-nacui-ruo-xing-jian-zhi-topatutimanezimentoshou-fa-falseshao-jie-1



ユーザベース

  • プロジェクトチーム編成方法や開発手法(TDD、DDD、クリーンアーキテクチャなど)を取り入れて、手動運用のオペレーションの自動化など、 SRE内でのソフトウェア開発を行っている事例を紹介。

当日発表資料:https://speakerdeck.com/tkitsunai/software-development-in-uzabase-sre




このような形で、各社発表後のビールを片手にピザを食べながら行ったディスカッションでは、当初21:30で解散の予定が23:00まで続くという盛り上がりを見せ、参加された方の満足度が非常に高い勉強会となりました。

今後のSRE Lounge

今後のSRE Loungeとしては下記のように考えています。

  • SREをテーマで、所属関係なく、横のつながりを生み出すコミュニティを作っていく(SREコミュニティ化)
  • どこか1社が主導してSRE Loungeを企画するというよりも、SREコミュニティ内の各社が主体となって、自律的に分散的に企画されるような形を目指す
  • そして様々な会社のオフィスで開催する

もし興味持ってくださり、参加希望の企業はこちらまでご連絡ください。

最後に

第2回開催の話も挙がりましたので、ぜひ今後も継続して開催していきたいと思います。

f:id:hir023:20180121203940j:plain
集合写真
f:id:hir023:20180121203932j:plain
今回参加したユーザベース SREチームメンバー




仲間募集!!

ユーザベースのSPEEDA SREチームは、No Challenge, No SRE, No SPEEDA を掲げて業務に取り組んでいます。
「挑戦しなければ、SREではないし、SREがなければ、SPEEDAもない」という意識で、日々ユーザベースのMissionである、「経済情報で、世界をかえる」の実現に向けて邁進しています。

少しでも興味を持ってくださった方はこちらまで