UZABASE Tech Blog

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

Chatwork、CrowdWorks、スタディスト、ユーザベースでSRE Lounge #2 を開催しました

こんにちは、ユーザベース SREチームでインターンをしております杉田です。 1/17(水)に始動したSRE Loungeの第二弾として、3/13(火)にSRE Lounge #2を開催しましたので、 今日はその模様を投稿します。

そもそも「SREとは?」といったことや、SRE Lounge開催の背景については、 SRE Lounge #1の記事に詳しく書きましたので、 ぜひご覧下さい。

今回も前回と同様に、

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

といったことを目的として開催しました。

開催日時

3/13(火) 19:00〜

開催場所

今回はChatWork様の東京オフィスをお借りして開催しました。 スクリーン付きのシアタールームがあったり、文字通り間近に東京タワーを眺めることが出来たりと、 とても素敵なオフィスでした。

f:id:ksksgtt:20180314193353j:plain
ChatWork様のオフィス

f:id:ksksgtt:20180314193926j:plainf:id:ksksgtt:20180314193959j:plain
会場の様子

参加企業

コンテンツ概要

  1. 各社の取り組み事例等の発表と質疑応答(各社20分程度)
  2. 発表を踏まえた座談会(30分程度)

ピザやChatWork様が提供して下さった飲み物で軽食をとりつつ行いました。

各社の取り組み事例等の発表と質疑応答

各社の発表内容を発表資料と共に以下にまとめます。

ChatWork様

マイクロサービスアーキテクチャを積極的に取り入れ、Kubernetes環境を運用しているとのことでした。 現在は新しいシステムはKubernetesで稼働させ、既存システムについてもKubernetesへ絶賛移行中とのことです。 また、サービスメッシュ(Envoy/Istio/Linkerd...)の採用検討もされており、非常に勉強になりました。 個人的には、技術負債(レガシー)をマイナスに捉えるのではなく、今までビジネスを支えてきた「レジェンド」なアプリケーションという風に敬意を持って呼ぶという点が心に刺さりました。

当日発表資料:microservicesとSRE (第2回 SRE Lounge)

www.slideshare.net



CrowdWorks様

Monitoringに対する取り組みとして、DatadogやAWS CloudWatch、その他周辺ツールの活用をしつつ、 さらにDatadogに連携するツールcyqldogを開発しているとのことでした。 また、Infrastructure as Codeの取り組みとして、ChefやTerraformを採用しつつ、 Terraformで作成したサーバーと、秘伝のタレ化したサーバーの差分を検出してくれるajimiを使って、コード化をスムーズにしているそうです。 OSSを活用するだけでなく、独自のソフトウェアを積極的に開発しOSS化している点は、弊社も見習いたいところです。

当日発表資料:SRE at CrowdWorks



スタディスト様

Monitoringでは、Fluentd・ElasticSearch・Kibanaの組み合わせやstackdriver・newrelicを、Infrastructure as CodeではAnsible・Serverspecを活用されているとのことでした。 さらに、組織的な取り組みとして、はてな様でも実施されているPerformance Working Groupという取り組みを行い、 SRE以外のチームメンバと計測数値や情報を共有し、議論する場を定期的に設けているとのことでした。 パフォーマンスを上げるためにSREだけで全ての範囲をカバーすることは難しく、SRE以外の開発メンバーの協力を必要とする機会は多々ありますので、こういった場を設けることは非常に大事なことだと思いました。

当日発表資料:デブサミ2018 で伝えきれなかった 快適なマニュアル作成共有を支えるSite Reliability Engineering



ユーザベース

ユーザベースの発表は今回で2回目なので、焦点を絞って日々発生するデータエラーについてどんな取り組みをしているか紹介しました。弊社が提供しているSPEEDAのプロダクトの要はデータです。一言にデータと言っても多種多様なデータの種類・形式を取り扱うため、データの抜け漏れやデータ同士の競合など考慮すべき点は多くあります。これをエラーが発生してから対応するのではなく、SREとしてvalidationを高度化し、先手を打つための仕組み作りについて発表しました。

当日発表資料:SRE Lounge#2 UZABASE



まとめ

形式は前回と同様ですが、発表後の懇親会の中で、各参加企業の

  • 異なる規模やSREとしての体制・内部事情
  • SREとして取り入れているノウハウ
  • 目指そうとしているSREのあり方

といったことをざっくばらんに共有し、議論する場を設けたことで、知識はもちろんお互いの交流を深めることが出来、非常に密度の濃い勉強会となりました。

SRE Loungeは、今後も継続して開催する予定ですので、もし興味を持ってくださり、参加を希望される企業の方はこちらまでご連絡ください。

f:id:ksksgtt:20180314180656j:plain
集合写真

f:id:ksksgtt:20180314180740j:plain
今回参加したユーザベース SREチームメンバー

仲間募集!!

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

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

【k8s合宿】 Kubernetesのメトリクスを取得する 〜PrometheusにGrafanaを添えて〜

こんにちは、SPEEDAのSREチームの阿南です。前回から少し時間が経ってしまいましたが、今回はKubernetesのメトリクス取得についてです。本番環境でkubernetesを運用する際、ポッドがどの程度リソースを消費しているのか、クラスター自体のリソースは大丈夫かなど常に把握しておく必要があります。ただ、Kubernetesってどう監視すればいいのって疑問ありますよね。PrometheusとかGrafanaとかよく出てきて概要は理解できるんだけど、実際どう構築すればいいの、とお悩みの方に役立つ記事にしたいと思います。ちなみに弊社ではRancher上にKubernetes環境を本番で利用していますが、大枠は今回紹介するような構成で運用しています。

構築する環境

f:id:tanan55:20180301095238p:plain

利用する環境はGKEです。まずKubernetesクラスターの中にPrometheusを構築し、メトリクスを取得します。さらに、クラスター外部にfederation用のPrometheusを構築し、Grafanaでメトリクスを可視化します。概要をざっくりと箇条書きすると、下記のようになります。

【クラスター内部(図の左側)】

  • KubernetesクラスターにPrometheus ポッドを稼働させる

  • Prometheus ポッドでクラスター内のメトリクスを取得する

  • NodeExporter ポッドをDaemonSetで稼働させ、Node(GCEインスタンス)のメトリクスを取得

  • Prometheus ポッドで取得したデータについては保持期間を1日とする

【 クラスター外部(図の右側)】

  • federationを使ってクラスター外部のPrometheusから値を取得

  • Grafanaでメトリクスを可視化

本記事では、まずKubernetesクラスターの中にprometheus ポッドを稼働させて値を取得するところまで紹介し、federationやGrafanaでの可視化周りは次回記事で紹介したいと思います。

構築手順

前回同様手順は別途まとめていますのでこちらをご参照ください。

Kubernetesの認証方式について

GKEのKubernetesバージョン1.8からはRBACがデフォルトで適用されているため、Prometheusで監視をする際に監視に必要な権限を与えてあげる必要があります。 さて構築する際のポイントですが、まずは自分自身のアカウント(kubectlを実行するユーザ)にcluster-adminを付与します。

$ gcloud info | grep Account
$ kubectl create clusterrolebinding anan-cluster-admin-binding --clusterrole=cluster-admin --user=sample-owner@sample-project.iam.gserviceaccount.com

cluster-adminを設定する理由は、kubectlを実行するユーザの権限より強い権限をroleとして設定することはできないためです。 ちなみにbindingには、clusterrolebindingrolebindingの2つがあり、それぞれ適用範囲をクラスター全体にするか、細かく設定するかを選択できるようになっています。この辺りの設計は利用するサービスや会社によって最適な設定が異なると思いますので、ぜひ事例があれば聞いてみたいですね。 次にPrometheus用にサービスアカウントを作成します。

$ kubectl create serviceaccount prometheus --namespace monitoring

このサービスアカウントに対して、参照権限を付与します。ここで、resourcespods, services, deploymentなどのリソースを表し、verbs がそのリソースに対する操作を表します。Prometheusは全てのリソースに対して参照権限を与えたいので、resources* とし、verbsget, watch, list の動作を許可します。nonResourceURLsはエンドポイントの権限設定なので、細かく設定する際は/api等のエンドポイントを指定します。今回はnonResourceURLs*、verbsをgetとしてエンドポイントに対してGETリクエストを許可します。これでread_onlyな形で権限を作成することができました。 Prometheusの監視について、secrets等は閲覧権限不要のため内容を修正しました。ご指摘いただいた方ありがとうございます!

gist.github.com

GKEの場合1.7まではデフォルトのサービスアカウントで全てのリソース、操作が許可されていました。Kubernetes v1.8からRBACがstableになっているのでGKE側でもこの辺りの変更が入っているようです。まだPrometheusにはたどり着いておりません。序盤からハマリどころ満載で、楽しくなってきました。

ConfigMap設定

ConfigMapにPrometheusのconfigファイルを設定します。最初のglobal設定で、メトリクスの取得間隔を指定しています。ポイントとして、 kubernetes_sd_configs を利用してメトリクスの取得先をdiscoveryできるようにしています。このservice discoveryの設定を利用することにより、サーバが追加になったりした際にも自動的にそれを検知しメトリクスを取得できるようになります。Prometheusの強力な機能ですね。

gist.github.com

kubernetes_sd_configsの中身については正直いきなり理解するのは難しいと思いますので、とりあえず細かい説明は置いて次に進みます。

Deployment設定

PrometheusのDeploymentの設定ですが、ここで最初に作成しておいたサービスアカウントが登場します。下記16行目にserviceAccountName: prometheusの記載があります。これを指定することで、全てのリソースに対する参照all-readerができるようにしています。ちなみに、サービスアカウントを作成するとsecretにca.crt、tokenというデータが作成されます。このsecretはポッドが起動した際に、自動的に/var/run/secrets/kubernetes.io/serviceaccount の配下にマウントされます。これをPrometheusのconfigに指定することでAPI Serverの認証をパスできるようにしています。先ほどのConfigMapの設定でca_filebearer_token_fileによくわからないパスが出てきましたがシークレットがマウントされていたんですね。この辺りの仕様は公式ドキュメントに記載がありますので見てみるといいと思います。Deploymentにサービスアカウントを指定しなかった場合、defaultのサービスアカウントが適用されますので、認証が通らずメトリクスの収集ができなくなります。だからと言って権限を全解放すると色々な事故が起こる可能性がありますし、後からこの認証を入れていくのはかなりしんどいと思います。最初から正しく仕事をする。頑張りましょう。

gist.github.com

Service設定とポート解放

Prometheusのサービスを公開します。今回はNodePortモードでノードの30001番ポートを解放しています。つまり、http://<Prometheus 稼働中 Node IP>:30001 にアクセスするとPrometheus ポッドの9090番ポートに接続されるので、Prometheusにアクセスするためには30001番のポートをGCPのネットワーク設定で解放しておく必要があります。GCPの管理コンソールのVPC ネットワーク > ファイアウォールルールからポートを解放してください。ちなみに、本記事では手間を省くためにNodePortモードを利用しておりますが、Production環境等ではInternalのLoadBalancerを利用した方がノードに依存することがなくなるため運用しやすいと思います。

最後に、Prometheusにアクセスしてみて下記のようにサービスディスカバリができていれば完了です! f:id:tanan55:20180305183938p:plain 結構難しいですよね。。。弊社の本番環境でもPrometheusを利用していますが、正直全てのメトリクスを把握できないほどの種類を取得しています。それだけ細かく取得できているのは素晴らしいのですが、どうやって可視化するのか迷いますよね。次回はそんな方にオススメのGrafana周りを紹介しますのでご興味のある方は楽しみにしていてください。

お知らせ

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

また、2018/03/15(木)にハートビーツ社主催で「SRE大全:ユーザベース編」 が開催されます。Youtube Liveでも配信されますのでご興味ある方はぜひご覧ください。

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

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を開催しようということが決定しています。

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