UZABASE Tech Blog

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

モンスト、スマニュー、Wi2の運用秘話多数! 「SRE Lounge #3」レポート

株式会社ユーザベースのSPEEDA Japan Company、Site Reliability Engineering (SRE) Teamの川口です。 先日、「SRE Lounge #3」という勉強会を開催しました。 発表企業4社のみ参加の非公開な会でしたが、ここでしか聞けないようなディープな話題が満載でした。

目的

「SRE Lounge」は、

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

といったことを目指して行われている勉強会です。

開催の背景や、そもそもSREとは何かについては、「SRE Lounge #1」の記事を参照してください。

開催日時

2018年5月17日(木) 午後7時30分 開始

会場

今回は、ミクシィ様本社のコラボレーションスペースをお借りしました。 広くておしゃれなカフェのような雰囲気で、窓からの眺めも良く、渋谷の夜景がきれいでした。 ランチや社内の打ち合わせだけでなく、今回のようなセミナーやイベントにも使用されているということです。

f:id:uzabase:20180522233522j:plain
会場のミクシィ様本社コラボレーションスペース

参加企業

※発表順

発表内容

当日のスケジュールは以下の通りです。

  • 各社の取り組み事例等の発表と質疑応答(各社20分程度)
  • 発表を踏まえた意見交換会(30分程度)

ピザやお酒を取りながら、終始和やかな雰囲気で行いました。

f:id:uzabase:20180522234242j:plain
スマートニュース様の発表を真剣に聞く皆様

ユーザベース 

企業・業界情報プラットフォーム「SPEEDA」のシステム構成の変遷を紹介しました。

サービスの成長に伴い、プロダクトチーム(dev)とSREチーム(ops)のやり取りでのオーバーヘッドが多くなったため、 開発チームだけでCI/CDまで完結出来る環境を構築しました。 具体的には、Kubernetes+Rancherの構成となっています。 クラスタレベルロギングアーキテクチャを採用し、各APから出力されたJSON形式のログを、fluentd経由でバックエンドのBigQueryに格納していることも特長です。

質疑応答では、アラート発生時の一次調査担当や、システム環境の統制などが多く挙がり、どの企業でも苦労されているようです。

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

ワイヤ・アンド・ワイヤレス様

「Wi2」などのWi-Fiサービスを提供されるワイヤ・アンド・ワイヤレス様には、 サービス提供環境のオンプレミス環境からクラウド環境移行への歩みについて、詳しく紹介いただきました。

オートスケーリングやコスト削減を期待してクラウドを導入したものの、なかなか思惑通りにいかず苦労されたそう。 しかし、少しずつ安定し、知識も得られてきたということで、サーバレス化やAWSの新しいサービスの利用も進めているとのことです。

Wi-Fiサービスならではの苦労も少なくない中、今後もアグレッシブに挑戦していきたいそうです。

当日発表資料:Sre wi2 20180517

f:id:uzabase:20180522234647j:plain
ワイヤ・アンド・ワイヤレス様発表中

スマートニュース様

ニュースアプリを提供されるスマートニュース様には、SREチームで担当されている膨大な業務範囲から、「モニタリング」「障害振り返り」の2つを紹介いただきました。

モニタリングでは、各リソースに適した様々なシステムを駆使しての監視を行っているということで、各社で参考になる部分も多かったと思います。

障害振り返りでは、障害発生時のインシデントレポート作成や、事後のインシデントレビューを行っており、再発防止策のトラッキングも工夫されているようです。 また、インシデントレビューの読書会も検討されているそうで、この辺りはまた詳しく聞いてみたいです。

質疑応答では、ニュースアプリならではの話題として、プッシュ通知時のアクセス集中対策の話が盛り上がりました。

当日発表資料:SRE at SmartNews

ミクシィ様

最後に、ミクシィ様のXFLAGスタジオから、「モンスターストライク」(モンスト)用に構築されているマルチクラウド環境について紹介いただきました。

「モンスト」のようなソーシャルゲームでは、例えばイベント期間だけ爆発的にアクセスが増えるため、サーバを短期間だけ増強する必要があります。 元々はオンプレミス環境で運用していましたが、最適な構成を模索するうちに、複数のクラウド環境を併用するに至ったそうです。 そのためのネットワーク構成や管理面での工夫や、各クラウドごとの癖についての話もありました。

SNSからの大規模サービス構築・運用ノウハウのあるミクシィ様ならではの内容で、当社とはスケールの違う話にワクワクしました。

当日発表資料:モンストのマルチクラウドについて / sre-lounge-at-xflag

発表を終えて

各企業のサービス内容やSREチームの守備範囲、SREに対する考え方など、これまでのSRE Lounge以上にバラエティーに富んでいて、とても興味深かったです。 また、各社の発表内容がディープで、質疑応答や意見交換会も大変活発でした。 当初予定していた時間を大幅に超えてしまいましたが、皆様多くのものを得られたのではないかと思います。ありがとうございました。

「SRE Lounge」は、今後も開催していく予定です。 興味を持たれた方や、発表してみたいという企業の方は sre@uzabase.com までメールにてご連絡ください。 また、Facebookの「SRE community」でも情報共有、交流を行っています。非公開グループですが、お気軽にご参加いただければ幸いです。

f:id:uzabase:20180522231824j:plain
今回参加いただいた各社の皆様

仲間募集!!

ユーザベースのSPEEDA SREチームは、 「No Challenge, No SRE, No SPEEDA」 を掲げて業務に取り組んでいます。

「挑戦しなければ、SREではないし、SREがなければ、SPEEDAもない」という意識の元、ユーザベースのミッションである 「経済情報で、世界をかえる」 の実現に向けて、日々邁進しています。

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

JaSST'18 Tokyoに参加してきました!!

こんにちは、ユーザベースのPDT(Product Development Team)です。

我々PDTは今年3月7日と8日にJasst’18 Tokyoに参加してきました。 今年のJaSSTではユーザベースはスポンサーとして協賛したので、私たち社員は無料で参加することができました。大変ありがたい話です。 今年もたくさんのセッションがあり、たくさん有用なお話が聞けました。 今回は私たちが参加したセッションについて紹介していきたいと思います。

各セッションの紹介

A1. 基調講演 「Advances in Continuous Integration Testing at Google」

Googleで長年CI/CDに取り組んできたJohn Micco 氏による講演でした。

Testing Scale at Google :

  • 420万件のテストが継続的に実行されている
  • 1日に1億5000万件のテストが実行されている(1日平均35回テスト実行)
  • 99%のテストがパスする

講演資料の2Pより http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf

まず規模感とテスト文化の説明があり、Googleは翻訳関連とUX関連のテスト以外はすべて自動テスト化されているらしく本当に圧倒的でした。。。 次に、これだけのテストをどうやって実行するのかのための施策として、必要なリグレッションテストケースの選定の話。 そして2日目のTutorialの内容でもあるテストメトリクスの分析について説明されていました。 定期的に実行される自動テストの結果から、バグを生んだコミットを探す方法やFlakyTests(不安定なテスト)を探すためのアプローチをかなり詳しく聞けてとても興味深かったです。

質疑応答では、マニュアルと自動テストの費用対効果の質問が結構出ていましたが、自動テストは当然なのでマニュアルテストとかありえない的な回答。日本のソフトウェア開発にこの文化が根付く日が早く来てほしいです。

E2. やってみよう!探索的テスト〜ハイクオリティな妄想の高速ループ〜

Jasst ’17 Hokkaidoの実行委員中岫さんと根本さんによる、ハンズオン形式の探索的テストのセッションでした。

このセッションではherokuに設置されたWebアプリケーションに対して、実際にみんなで探索的テストをやってみるといった内容でした。私は開発者なので、普段は「期待通りに動いていること」を保証するテストなら自動テストで行なっています。しかし、バグを叩き出すことを目的としたテストはあまり経験がないので非常に新鮮な体験なりました。ちなみに多い人は20個ほどバグを発見できたそうですが、私は2個でした(笑)。

最後に他の方達とどんなバグを出したかを話す時間がありましたが、そこで出たバグの内容の違いに驚きました。私が見つけようとしていたバグは、システム自体が使い物にならなくなるようなバグのみでした。しかし、他の方はユーザにとって使い勝手が悪いと感じる仕様や、通常の運用ではしないような入力を与えたことで発生する事象もバグとして記録していました。開発のエンジニアとテストエンジニアとの間でテストの視点が全く違うのだなぁと感じました。

C4-1. 探索的テストにおけるストーリーベースのアプローチ

NTTデータ熊川さんによる探索的テストに関する研究発表でした。

タイトル的にアジャイル開発でよく聞く「ストーリー」のことかと思いましたが、ここでのストーリーは本来の意味の物語をさしています。人間は自身の体験を物語形式のパターンとして当てはめる傾向があるらしいです。熊川さんの手法は探索的テストで利用するチャーターを物語の形式にすることで、テスターの知識や経験を探索的テストに反映させやすくするというアプローチを取っていました。

結果としては、従来手法より圧倒的に優れた訳ではありませんでしたがアプローチそのものは非常に面白いと思いました。

C4-2. NGT記法を応用した不具合分析からのテスト補強

ベリサーブ吉川さんによる、足りないテストケースを補うためのアプローチに関するセッションでした。

NGTとはテスト観点図を作成するための表記法です。吉川さんはテスト観点ではなく、発見した不具合の持つ要素にたいしてNGTを適用して不具合分析を行い、導出した要素から別のテストケースを作る手法を提案していました。結果としては提案手法を使うことで、既存のテストケースだけでは取り逃がしていた可能性のある不具合を見つけることができていました。

個人的には不具合の持つ要素も結局はテスト観点になるのではないかと思います。本来、テストに必要になりそうな要素ならなんでもテスト観点になり得ます。なので不具合そのものはテスト観点でないにしてもそこから導出される要素はやはりテスト観点だと考えられます。そういう意味では、このセッションの本質はテストフェーズでテストアーキテクチャを見直しませんか?という提案ではないかと思いました。

D4.「無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化」

元ゲームプログラマであり「龍が如くスタジオ」専属QAエンジニアの阪上さんによる、テストの自動化とそのログ解析方法についてのセッションでした。

セッションのメイントピックは kibana + fluentd + elasticsearch を組み合わせたデバッグログの分析だったのです、その前段として、自動テストでゲームを全クリできるほど自動化されているというのが衝撃でした。実際にキャプチャ/リプレイでオートメーションされたテストのデモも見れて面白かったです。 自動テストをバグ出しのために使うだけでなく、テスト結果を分析してゲームのチューニングに利用しているという1つ上のレベルの取り組みをされていて日本企業でここまで成功している事例があることに驚きました。

B5. ケーススタディで学ぶ仕様の書き方

川口さんによる、形式手法に関するセッションでした。

形式手法は仕様を厳密なルールで記述することで、仕様の曖昧さを排除できたり、仕様の矛盾をプログラムで自動的に発見できるなど非常に高度な手法です。川口さんは組み込みシステムの振る舞いの仕様を状態遷移図を使って形式化し、それに対してモデル検査をかけて曖昧な点や矛盾をなくすアプローチについて説明していました。

しかし、このセッションで最も有用だったのは形式手法そのものより、既存のシステムにたいして新しい機能を追加しなければならない状況で、1から仕様書を作成するときのノウハウを共有していただけたことだと思います。具体的にどうするかというと、新しい仕様については全て状態遷移図を書きます。その時に既存の部分と密接な関わりがあるならば、新しい仕様の状態遷移図に対して既存の仕様の要素を追加します。つまり、新しい部分は全て記述し、既存の部分は必要な分のみ追加するということです。既存の部分に対してまで、網羅的に仕様書を作っているとコストがかかりすぎるのでこのようなアプローチが重要なようでした。

E5. 海外のテスト技術動向 ~カンファレンス、国際会議、海外テストチームの現場から~

パネリスト:辰巳さん、松尾さん、山口 さんによる海外のカンファレンスや海外でのテストチームの編成に関するセッションでした。

辰巳さんのパートでは、海外のソフトウェアテストのカンファレンスについて概要と歴史などを紹介されていました。 2018年も海外でこんなにカンファレンスがあるようです。http://www.softwaretestingmagazine.com/software-testing-conferences/

やはり日本よりも海外のほうがだいぶ先行していることを改めて感じました。 印象に残ったのは、どうやって情報収集しているのかという質問に対して「SNSやネットでひたすら追いかけている」と応えていらっしゃったことです。興味があるものに関して言語を超えて情報収集し、そこから更に発信していく姿勢にとても刺激を受けました。

続いて、山口さんのパートではSTARWESTとAgileTestingDaysに実際に参加した感想を発表されていました。 STARWESTはディズニーランドホテルでやってるとのこと。参加費がJaSST’の8倍くらいかかってるのに参加者は同じくらいいるそうです。 ソフトウェアテスト製品のベンダーがスポンサーにたくさんついていて、講演者も多いとのこと。講演者と講演後に個別に質問などができる機会が設けられているが質問というより営業に近いと言っていたのも日本とは違うなという印象でした。

最後に、松尾さんが海外にテストチームを組成する際の経験談についてお話しされていました。Uzabaseでも海外開発チームの組成を進めていますが、やはり大変なところは採用というのは共通してるようです。実際に自分で海外企業の面接を受けてみて知見をつけてから採用活動に取り組んでいるというお話もされてました。優秀な人材を見つけるにはちゃんと調査や準備が大事ということですね。

セッションを通じていえるのは、日本にとどまらず海外の事例に学ぶ姿勢を持つのが大切だということです。パネラーの方々のように積極的に良いものを探し出して取り込んでいけると理想的ですね。

A7. 招待講演 「私が経験したソフトウェアテストの変遷」

現在のソフトウェア開発にいたるまでの「技術的変遷」とTDD、CI/CDのお話し。柴田さんご自身の富士ゼロックス、リコーでデジタル複合機の開発をされた際の経験談についての講演でした。

前半では、過去の偉大なエンジニアたちがいかにしてTDDにいったたのかをわかりやすく説明されていて、その意義を再認識しました。最初にテストコードを実装してからプロダクトコードの実装をすることで、開発者へのフィードバックループをいかに短くし、すぐにバグや設計ミスをすぐに修正できるようにする、というTDDの手法はUzabaseでも導入していますが、品質とスピードを担保するためにすごく考えられて作られた手法なのですね。過去の偉人に感謝。

後半のご自身のマルチスレッドプログラミングに関するトライ&エラーの経験談で印象にのこったのが、開発者全員が毎晩自動テストを実行していたところ、3か月前にコミットされたコードに問題があることが発見されてとのお話しでした。これも自動テストがなければ絶対見つからないよねって感じで自動テストってほんとに大事だと思わされました。 自動テストを大切な資産ととらえて開発チームみんなで認識してメンテナンスしGREENにし続けていかなければと強く感じました。

終わりに

いかがだったでしょうか。 JaSSTでは本当にたくさんのセッションがあり、非常に勉強になります。 周りきれなかったセッションもありますがそちらもきっと為になる話が聞けのではないかと思います。

JaSST'18 Tokyoゴールドスポンサーとして協賛しました!

こんにちは! SPEEDAのテストエンジニアをやっている工藤です。

ユーザベースとして、2018/03/07(水)ー03/08(木)に開催された JaSST'18 Tokyo を協賛いたしました。
今回は協賛した理由とそこから読み取れる弊社でテストエンジニアとして働くことの価値を書きます。

f:id:kudogen:20180320101504j:plain

JaSST Tokyoとは

JaSST Tokyoとは業種や職種を問わずソフトウェアテストに関心がある方が一同に集まる、国内最大のソフトウェアテストシンポジウムです。
JaSST’18 Tokyoには2日間で延べ1600人を超えるエンジニアが参加し、一時Twitterのランキングで6位になるなど大盛り上がりのカンファレンスでした。
当日盛会の様子は下記からご覧ください。
JaSST Tokyo実行委員ブログ
JaSST'18 Tokyoレポートページ

ゴールドスポンサーとして協賛した理由

この度は、

SPEEDA開発でも様々なOSSを利用したりとコミュニティ活動の恩恵を受けているので、このような活動をサポートすることでコミュニティに還元していきたい。

という想いでゴールドスポンサーとして協賛いたしました。

元々SPEEDA開発では、エンジニアがコミュニティ活動などに積極的に関わることが推奨されています。
そんな背景もあり、私(工藤)もJaSST Tokyoの実行委員として活動しておりました。

特にテストはSPEEDA開発において最も大事にしていることの一つなので、ゴールドスポンサーという形でソフトウェアテストのシンポジウムを協賛できたことはとてもうれしく思っています。

SPEEDAプロダクトチームでテストエンジニアとして働くことの価値

今回、JaSST Tokyoを協賛・参加して改めて「SPEEDAプロダクトチームでテストエンジニアとして働くことの価値」について考え、以下に挙げてみました。

  • 基本的に各チームに権限が委譲されているので自動テストや新技術の導入はエンジニアドリブンで行うことができる
  • テストを下に見るような変な風潮はない
  • チームとしてテストを大事にしているからこそ、テストエンジニアとしては価値を出しやすい
  • 常にチームとして技術的なチャレンジを行っているので、エンジニアとして成長しやすい環境がある
  • テストエンジニアも開発チームの一員となって動くので、開発側の知識もつけていける
  • 前述の通り、コミュニティ活動などに理解があり、推奨されている

今後もSPEEDA開発として、JaSSTのみならず様々なコミュニティ活動に貢献していきたいと思っています。

現在、技術的にチャレンジしたい、成長したいテストエンジニアを募集しております!
少しでも気になった方はこちらまで