Cybozu Inside Out | サイボウズエンジニアのブログ

 

デザイナー発案で実現した、製品新デザイン化の学び

こんにちは、サイボウズ デザイングループの@kochitakuです。Garoonという中堅・大規模組織向けグループウェアを担当しています。最近クラウド版Garoonのデザインが新しくなったのですが、新デザイン化はデザイナー発案で始まり、いろいろな人を巻き込みチームワークで実現しました。この記事ではその時に得た学びを紹介します。細かいデザイン変更内容については割愛し、汎用性を意識して書きました。読んでいただいた方に1つでもお土産があると嬉しいです。

新デザインについて

PC用Web画面の変更をしました。 デザイン変更イメージ

製品内にユーザーさんからフィードバックをいただけるしくみを用意しまして、「気に入っている」を一番多くいただきました。

  • 気に入っている:563件
  • 不満がある:459件
  • アイデアがある:75件

厳しいご意見も全部確認して改善検討の材料にしています。何より1,000件以上のフィードバックをいただけたことに感謝しています。 フィードバック結果の棒グラフ

一番大きい自社イベントのCybozu Daysでも大きく紹介されました。会場で見ていて胸が熱くなりました。 イベントの写真

新デザイン発案のきっかけ

以前のデザインは5年以上前のもので、社内外の声からもモダン化への必要性を感じていました。サイボウズにはデザイナーが自主的に提案する風土があり、「More Modern活動(通称:MM活動)」と勝手に名乗り活動を始めました。「MM」と言い続けたところ、まわりにもどんどん認知されました。言葉って流行るのですね! 今回の新デザイン化はMM活動の第一弾で、その後も活動は継続しています。

まわりの心を動かす

自主的に活動を始めるのは簡単ですが、ステークホルダーの共感がなければものごとが進みません。サイボウズの場合、最初にPM(プロダクトマネージャー)の心を動かすことが必要です。どのように心を動かし、共感を得たかを紹介します。 まわりの心を動かす図

価値の共感

新デザインの軸を「トレンド(見た目・操作・効果)」「社内他製品との親和性」「アクセシビリティ」として、それぞれの価値を説明しました。ざっくり「モダンにしたい」だけでは説得力が乏しく、価値を探求して軸を決めました。

リスクの共感

やらないことへのリスクを説明しました。時には危機感をあおることも必要だと思います。 また、変えることへのリスクヘッジも非常に大切です。結果として今回は以下のように段階的に広げて、フィードバックを得ながら進めました。社内で実際に利用している製品という利点を活用しています。

  • 社内:開発メンバー

   

  • 社内:幅広い部署のメンバー(限定) 

   

  • 社内:全体

   

  • 社外:お試し用でリリース

   

  • 社外:正式リリース(デフォルトデザイン変更)

過去の経験から旧デザインも選択できる提案もしました。メンテナンスコストも考慮してCSSレベルで旧デザインをある程度保持できる仕様になりました。

コスト情報

PMが工数を判断しやすいよう、できるだけ正確なコスト情報を用意できるのが理想です。デザインの理想を追求すると開発全体のコストがどんどん膨らんでいくので、PGの工数を抑えた「html/CSS/image変更レベル」などレベルを分けた話をしながら詰めて行きました。松・竹・梅のイメージです。

価値の実感

今回はこれが一番ポイントだと思っています。前述のとおりGaroonは社内でも利用していて、社内環境で手軽に新デザインを疑似体験できないか考えました。掘り下げていくとCSS/imageの変更である程度は新デザインを実現できることわかったので、Stylishという自作のCSS/imageを適用できるChrome拡張を使って疑似体験の拡散に成功しました。これにより価値の実感の啓蒙が進み、正式リリースに向けて加速がつきました。

プロトタイプツールやテスト環境でのお試しより、普段の環境での疑似体験はかなり強力です。Stylish上のCSSを外部リンクにしておけば、フィードバック対応もリンク先のCSS変更だけで済むのでオススメです。 Chrome拡張を使ってもらいやすいよう、画面キャプチャ入りのマニュアルも用意しました。途中でつまずくと使ってもらう率が減るので、こういったマニュアルには労力を惜しまない方が良さそうです。

マニュアルの見本
実際のマニュアル
ちなみにサイボウズのデザイングループ内にはChrome拡張を自作する猛者もいます。自作が厳しい場合、PGに相談もオススメします。

専任PMの存在

Garoonは3人のPMがいるのですが、PMに相談して新デザイン化のあらゆる決断ができる専任PMを1人決めてもらいました。デザインの議論は好みに依存するケースもあり、決定スピードが鈍くなる過去の経験からの学びです。多忙なPMの予定調整やオンラインでの返事待ちコストも抑えることもできます。実際、専任PMのスピード感ある判断の連続でスムーズに進みました。

最後に

デザイナーの発案はきっかけにすぎず、たくさんの英断をしたPM、たくさんの画面を実装したPG、テストしたQA、ヘルプのキャプチャを刷新したTC(テクニカルコミュニケーション)、外部発信に尽力したマーケティングメンバー、その他大勢のメンバーやユーザーさんのフィードバック、問い合わせ対応しているサポート…とにかくたくさんのチームワークによって新デザイン化は実現に至りました。本当に良い経験ができました。ありがとうございます。

先月ベトナムでGaroon開発メンバーが集うMeet Upがあったのですが、新デザインのLTをしてきました。夜のKARAOKEは異常に盛り上がりました。。。 Meet Up・カラオケの写真

私事ですが最近は内弁慶を脱すべく社内外のデザイナーイベントにときどき参加していますので、なにか質問があればお声がけください。

関連リンク

 

QA若手メンバーへインタビュー

f:id:cybozuinsideout:20180611104003j:plain

こんにちは!品質保証部の中園です。

本記事では、品質保証部(QA)に所属して2年目となるQA若手メンバーにスポットを当て、 現在の仕事内容や、QAのやり甲斐などをインタビューしてみました。

インタビューした若手メンバーの紹介

三牧さん: 2016年新卒入社。QA配属後、kintoneの試験業務を担当。 現在はkintoneと、そのモバイルアプリのQA責任者を担当。

小山さん: 2016年新卒入社。Garoonの不具合調査や問い合わせ対応を担当した後、 2017年7月から Garoon 開発のスクラムチームに参加。趣味は読書。

森さん: 2016年新卒入社。Site Reliability Engineeringチーム(SRE)でQAを担当。趣味はペンシルパズル。

普段はどういった仕事をしているのですか?

三牧さん: kintoneと、モバイル版kintoneのQA責任者をしています。 主に、PGやPMとリリーススケジュールの調整をしたり、試験進捗などの管理をしています。

その他にも、バグのトリアージや、試験仕様書のレビュー、試験の実施もやっています。 PGやPMとの調整以外にも、試験に関わることであれば何でもやっています。

小山さん: Garoon 開発チームに所属しています。チームでは試験設計や試験実施など試験関連のタスクと、仕様書のレビューを行っています。

Garoon ではスクラム開発を取り入れているのですが、スクラムイベントでも QA の観点から積極的に発言するようにしています。 (ここの処理では新しいエラーを追加しますか?とか、これも影響範囲に入りますか?とか) 最近ではテスト自動化のマネジメントも行っています。

スクラム開発については、Cybozu Meetup #11 アジャイルQAで発表した資料があるので、詳細はこちらをご覧ください。 speakerdeck.com

森さん: SREチームでQAをやっています。主に、SREが作ったコマンドの試験や、自動テストの作成をしています。 仕事では基本的にシェルを使っています。 今年の3月末まで、半年間ほどSREと兼任もしていました。

試験業務以外にも、開発環境の管理もしています。 開発環境で障害が起きたときの対応や、利用しているメンバーへのアナウンスなどをしています。

中園:2年目とは思えないほど、皆さんそれぞれのチームで活躍していますね!

どうしてQAになろうと思ったのですか?

三牧さん:学生時代からQAのアルバイトをしていました。 そこで、QAにやり甲斐を感じており、将来はQAになることを目指していました。

森さん:私は最初、QAを志望していたわけではなく、PGを志望していました。 就活のときもQAという職種は知らず、PGで受けていました。 入社後の全体研修でのQA体験で、不具合を見つけたときの喜びが忘れられず、QAを志望しました。

中園:QAのやり甲斐や面白さに気づいてしまったのですね。その気持ち分かります。

QAの仕事のやりがい、面白いところはありますか?

三牧さん: 仕様の穴を見つけたときや、不具合を見つけたときですね。 リリースプロセスの最後に、製品の保証をしているところに責任感はありますが、その分やり甲斐を感じています。

あとは、スケジュールを組み立てたり、調整したり、試験プロセスにチームの要望をとりいれて改善していくことは面白いですね。 目に見えて改善の効果が出ているときは嬉しいです。

関連:Cybozu Meetup #11 アジャイルQA発表資料

www.slideshare.net

サイボウズ自体そうなのですけど、やりたいことをさせてもらえる、チャレンジできる環境があることは素晴らしいと思います。

小山さん: 自分は複雑なものをわかりやすく表現することに面白さを感じるので、試験設計時に仕様を整理したりモデル化したりするのが好きです。

配属後しばらくは、社内のテクニカルサポートからの問い合わせに対応する業務を行っていました。 このとき、製品のリリース後に不具合が発覚するとお客様に迷惑がかかりますし、製品の信頼度も下がってしまうということを身をもって知りました。 そこで、開発プロセスの上流工程で不具合を作り込まない活動をしたいと思うようになりました。

今はスクラムチームに入り、それを実現しています。 これは品質保証部だけでなくサイボウズ全体にも当てはまると思いますが、やりたいことを相談できる環境が整っていると思います。

中園:問題点を見つけ、自ら改善しようとする姿勢が素晴らしいですね。

QAになって辛かったこと、大変だったことはありますか?

小山さん: Garoon の不具合調査や問い合わせ対応を担当していたころは、なかなか回答が出せないと辛かったですね。テクニカルサポートのメンバーや、その先にいらっしゃるお客様をお待たせしてしまうことになるので。

最近はテスト自動化のタスクも抱えているので、少し忙しいですね。TEともうまく相談しながら進めていきたいと思っています。

参考:テストエンジニアリングチーム(TE)について blog.cybozu.io

森さん: 緊急リリースの時が大変ですね。 急がないといけないのですが、試験もしっかりしないといけないので、 こういう時でも、いかに冷静さを保つかが重要ですね。

QAとして、チームで働くうえで大事にしていることはありますか?

三牧さん: 対話することを大事にしています。コミュニケーションが大事ですね。 チームで仕事をしているので、メンバーとの意見交換をマメにするように意識しています。

あとは、物事をわかりやすく・早く伝えることです。 例えば、試験中に不具合が発見されたら、出来るだけ早めにPGに共有しています。 早ければ早いほど、不具合の改修を直近のリリースに含めることができたり、改修に時間がかかるような不具合だと、リリースを遅らせてしまう可能性もあるためです。

小山さん: 「QA だから○○をする」「QA だから○○をしない」という風に考えすぎないようにしています。QA 的な業務がメインですが、それ以外のところにも関与したいと思っています。

PG が何を考えてどういう仕事をしているか把握したり、QA 以外のメンバーに試験仕様書の見方を教えたりなどをしています。 自分が QA 以外の仕事を知ることや、チーム全体で品質について関心を持ってもらうことが、最終的には製品の品質の向上につながるのではと思っています。

あとはチーム全体では「謙虚・尊敬・信頼(HRT)」の精神が大事にされているように感じます。 互いを尊敬しながらも、気を使いすぎないよう、しかし言うべきことは言う。 それが実現できているのも、チームメンバーが皆HRTを大事にしているからだと思います。

森さん: 自分以外のメンバーのための行動をすることですね。 たとえば、他のSRE QAメンバーのために、 試験をしたときの手順やログを残しておくことです。 似たような改修をするときに、以前どのようなログが出たのか、どのような試験をしていたか、など 記録から参考になることはたくさんあります。

今後どのようなことにチャレンジしたいですか?

三牧さん: 直近だと、リリースサイクルを短くすることがチーム内のテーマです。 今は2~3ヶ月に1度のリリースなのですが、それをもっと短縮しようとしています。 それに合わせて、QAがやる試験も柔軟に変えていきたいと思っています。 高い品質を保ちつつも、早くリリースできるようチャレンジしていく予定です。 具体的に言うと、試験に関わることを、もっともっと自動化したいですね。

小山さん: 直近だと、まだ始まったばかりの自動テストを安定運用までもっていきたいです。テスト結果の安定と、ルールの浸透を目指します。 Garoon 開発で複数チームでのスクラムを行っているので、共通の指針としての品質目標やテスト戦略の整理もしてみたいですね。 実装にも興味があるので、機会があればテストファーストなコーディングにも挑戦したいです。

森さん: テストの自動化にチャレンジしていきたいです。 といっても、今まさにテストの自動化はやっているのですが、 テストの準備など、テスト以外でもできるところは全て自動化していきたいですね。

中園:3人とも”自動化”というのがキーワードですね。自動化がこんなに熱いとは!

最後にひと言

三牧さん: これからもいろいろなことにチャレンジして、品質の向上に貢献していきたいです。 あとはそうですね、kintoneのQAは人が足りないので、メンバーを絶賛募集中です。

小山さん: 私のチームもやりたいことに対して人数が足りてないので、ぜひ来てください。 これまでやってきたことにかかわらず、論理的に考えることが得意な方や、物事を順序立ててすすめたい方、細かいことに気がつく方は、QAに向いていると思います。

森さん: QAは責任感ある仕事で、その分やりがいがある部署です。毎日が楽しいです。 これからも、品質の面から、サイボウズ製品を支えていきたいと思います。

QAの仕事に興味をもった方へ

本記事でサイボウズのQAについて、雰囲気の一端を紹介できたのではないかと思います。

この夏、学生向けのインターンシップを開催します。 実際にサイボウズのQAを体験できますので、興味のある方はぜひご応募ください! (応募締め切り:6月30日)

blog.cybozu.io

また定期的にMeetupも開催していますので、こちらもチェックしてみてください。

Cybozu Inside Out - connpass

品質保証部では、新卒とキャリア採用を行っています。 私たちと一緒に働く仲間を募集中です!

www.wantedly.com

 

アクセシビリティの祭典2018参加レポート

こんにちは。デザイングループの小林(@sukoyakarizumu)です。 5月17日、神戸で開催された「アクセシビリティの祭典」というイベントに、弊社の杉山(@oogFranz)と2人で登壇しました。この記事では、当日の様子と、自分が登壇したセッションについて紹介します。

「アクセシビリティの祭典」とは?

アクセシビリティとは、高齢者・障がい者を含めて、すべての人が製品やサービスを利用できることを表す言葉です。
アクセシビリティの祭典は、神戸で開催されるアクセシビリティに関するお祭りです。Web制作会社や障がい者支援の機材を開発する会社など、多くの企業が参加・協賛しています。サイボウズも協賛企業のひとつです。

当日の様子

当日は、視覚障がいや聴覚障がい、身体障がいを持つ車椅子の方など、多くの方が参加していました。どんな参加者にも情報を伝えるため、会場の情報保障がとても充実していました。どのセッションにも手話通訳がつき、かつ、発表者の発言内容が自動的に字幕に書き起こされ、さらに英語に翻訳された結果とあわせて表示されるようになっていました。

下の写真はセッションの様子です。手話通訳と日英の字幕が表示されていることがわかります。

セッションの様子
セッションの様子。向かって右側に手話通訳と日英の字幕が表示されている。
セッション自体にも、障がい者の方が多く登壇され、手話を使って登壇したり、視線入力装置などを使って、ご自身の生活状況を伝えたり、最新の情報機器の活用事例を伝えていました。支援機器やWeb技術の発展によって、多くの障がい者の方が積極的に情報を入手したり身の回りの問題を解決している姿がとても印象的でした。

会場に設けられた展示ブースにも、障がい者の方を支援する情報機器や、アクセシビリティに関するツールが多数展示されていました。

運転中の電動車椅子
電動車椅子。左右の歯を噛みしめるだけで前進や後退、左右転回ができる。

視線入力装置を取り付けたノートPC
視線入力装置を取り付けたノートPC。視線でカーソルをボタンに合わせ、注視で確定する。

登壇したセッション

私たちは、セッション「トークバトル60分一本勝負「禁断の対決!サイバーエージェント vs サイボウズ」」に登壇しました。 このセッションは、サイバーエージェントさんの桝田さん・土岐さんと一緒に、freeeの伊原さんも交えて、Webサービスでアクセシビリティを確保する取り組みについてトークバトルするという内容でした。 セッションは口上を交えながら、プロレステイストで入場するスタイルでした。

セッション中は、サイボウズのアクセシビリティの現状についてお話ししました。
サイボウズは、アクセシビリティを「ユーザがチームにアクセスできる能力」ととらえ、アクセシビリティの確保に取り組んでいます。 もともと一部の有志メンバーがはじめた取り組みでしたが、今では多くの開発チームが自主的に活動を行うようになりました。 また、広報や営業など、開発以外の部署にもアクセシビリティに興味を持つ社員が増えてきました。
アクセシビリティの取り組み - サイボウズ

社内では勉強会が活発に行われています。アクセシビリティに関する書籍を輪読したり、製品のテストをしてみたり、障がい当事者による講演会やユーザビリティテストを開催したりしています。

また、製品の改善も少しずつ進んでいます。特にデザインのリニューアルの際には、アクセシビリティの確保がコンセプトの一つとして組み込まれるようになりました。 今年2月〜5月にかけて行われたサイボウズガルーンのデザインリニューアルでも、コンセプトの1つとしてアクセシビリティが挙げられています:
新デザインのご紹介 - サイボウズガルーン

サイバーエージェントさんも、多くのアクセシビリティ改善を行っているようでした。特にFRESH!というサービスは、 WebアクセシビリティのJIS規格である「JIS X 8341-3」への準拠を目標としているとのことでした。国内Webサービスでの準拠は前例がなく、素晴らしいチャレンジだと思います。 また、多くの社員の方が関わり、わかりやすいアクセシビリティガイドラインをつくっていることも、とても印象的でした。

お互いの取り組みには共通の悩みも多く、「バトル」を意識して相手に不足しているところを攻めると、そのまま自分の弱点を突いてしまうようなところもありましたが、充実した議論ができました。

余談:実況スレッド

サイボウズには、社内イベントや会議中に、コメントを自由に書き込む「実況スレッド」というコミュニケーションスペースがあります。セッション中は、弊社の多くの社員が実況スレッドに感想を書き込んでくれていました。

当日はサイバーエージェントさんの動画サービス「Fresh!」で生放送が行われており、 会場にいない社員にも、オフィスにいながらセッションの内容を体験してもらうことができました。情報保証の大切さを実感しました。

セッション中に実況スレッドで多くの社員が感想を書き込む様子
セッション中の実況スレッドの様子

 

ざっくりわかった気になるモダンGC入門

どうも!@yokotaso です!

2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。

現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。

発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます!

発表資料は、speakerdeck にあります。はじまり〜はじまり〜

はじめに

f:id:cybozuinsideout:20180527142809p:plain:w300f:id:cybozuinsideout:20180527142805p:plain:w300

今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。

現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。

さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。

次にShenandoahGC、ZGC、Epsilon GCと3つ紹介します

これまでのGC

f:id:cybozuinsideout:20180527142801p:plain:w300

まずは、これまでのGCについて少し

f:id:cybozuinsideout:20180527142757p:plain:w300

まずはParallel GCです。young/old領域でわかれたメモリ管理をしておりまして、これに合わせてyoung GC/old GCを行います。 この世代を分けるメモリ管理ですが、多くのGCで採用されています。

young/oldのGCそれぞれで、コンパクションGCをします。GCスレッドが動いている間は、アプリケーションスレッドは停止します。

f:id:cybozuinsideout:20180527142754p:plain:w300

次にコンカレントマークスイープGCです。young領域はコンパクションを伴うGCをします。

Old領域はコンパクションを行わず、アプリケーションスレッドを動かしながらマーキングと呼ばれるゴミオブジェクトの確定作業をします。

ゴミが確定したオブジェクトの領域はメモリは開放されて再利用されます。

マークスイープ型GCの問題点としましては、old領域がフラグメントし、メモリ利用効率が悪くなる問題があります。

f:id:cybozuinsideout:20180527142750p:plain:w300

そしてG1GCです。メモリを細切れのサイズに分解するリージョン型のメモリ管理をしています。リージョンごとにyoung/oldなどの世代を設定します。

young GCはアプリケーションスレッドを停止してコンパクションGCをします。 old GCも同様にアプリケーションスレッドを停止しますが、目標停止時間を定めてGCをします。

young/old gcはコンパクションGCなので、メモリのフラグメントはしません

f:id:cybozuinsideout:20180527142746p:plain:w300f:id:cybozuinsideout:20180527142743p:plain:w300

3つのGCをまとめて見てみます。

今利用できるGCはコンパクションGC時にアプリケーションスレッドの停止が発生します。これは、young/old GC関係なく発生してしまいます。

逆にコンパクションGCをしないとメモリがフラグメントしていきます。メモリ利用効率が悪くなってしまうわけです。

なぜ新しいGCが必要になっているのか

f:id:cybozuinsideout:20180527142739p:plain:w300f:id:cybozuinsideout:20180527142735p:plain:w300

こういった話を踏まえて、なぜ新しいGCが提案されるようになったのかを見ていきましょう

ひとつは巨大なヒープを利用するアプリケーションの台頭です。

こういったアプリケーションの場合、young領域も大きくなる可能性があるので、コンパクションGCに伴うアプリケーションの停止も無視できなくなってきます。

あわせて複数コアや大量メモリといったハードウェア上の進化もあり新しいGCの必要性がでてきています。

Shenandoah GC

さて、前説を終えたので、Shenandoah GCを見ていきたいと思います

f:id:cybozuinsideout:20180527142731p:plain:w300f:id:cybozuinsideout:20180527142727p:plain:w300

こちらredhat社によって開発されています。 100GBと2GBの停止時間がかわらないという触れ込みです。

なお、利用したい場合はバックポートしてjavaをビルドしなおせば利用できます。

f:id:cybozuinsideout:20180527142724p:plain:w300

GCの特徴としましては、これまでのGCで利用されていた世代型メモリ管理をしません。 G1GCと同じリージョン型のメモリ管理を採用しています。

並列マーキングは他GCでも行われていますが、このGCの特徴として並列コンパクションを採用している点があります。

アプリケーションと並列で動くコンパクションがなぜ難しいのかを見ていきましょう。

f:id:cybozuinsideout:20180527142720p:plain:w300

アプリケーションと並列に動作するため、コンパクションGCに伴うオブジェクトの移動とアプリケーションスレッドの参照の更新が同時に起る可能性があります。

GCの実装を工夫しないと、捨てる予定のオブジェクトを参照してしまう危険性があります。

f:id:cybozuinsideout:20180527142717p:plain:w300

これを解決するために、JVM内部のオブジェクトの中にポインタとは別にBrooks pointerと呼ばれるヘッダをつけて解決しています。

オブジェクトが待避されていなければ、自分自身のポインタをヘッダが指すようになります。この図でいうと右の図です。

オブジェクトが待避済みの場合は、ポインタは待避後のオブジェクトを参照するようにします。この図で言うと左の図です。

f:id:cybozuinsideout:20180527142713p:plain:w300

このおかげで、待避前・待避後のオブジェクトであっても、ポインタを辿って、待避後のオブジェクトを参照できるようになります。

f:id:cybozuinsideout:20180527142708p:plain:w300

アイデアのキモは説明できたので、GC全体を眺めてみましょう。

f:id:cybozuinsideout:20180527142705p:plain:w300f:id:cybozuinsideout:20180527142701p:plain:w300

まず、アプリケーションスレッドを停止してルートから辿れるオブジェクトをマークしてきます。

次にアプリケーションと並列でInitial-Markでマークしたオブジェクトをさらに辿っていきます。

f:id:cybozuinsideout:20180527142657p:plain:w300

アプリケーションスレッドを停止して、前のフェーズから変更があったオブジェクトがゴミオブジェクトになっていないかの最終確定をします。

f:id:cybozuinsideout:20180527142654p:plain:w300f:id:cybozuinsideout:20180527142650p:plain:w300

あとは、ゴミオブジェクトの多いリージョンがマーキングでわかっているので、そのリージョンに対してコンパクションGCをしていきます。

f:id:cybozuinsideout:20180527142644p:plain:w300

説明したBrooksポインタで古いオブジェクトの参照を新しいオブジェクトのヘッダに付け替えていきます。

このフェーズはアプリケーションが並列でうごいているので参照の更新がおこります。

f:id:cybozuinsideout:20180527142640p:plain:w300

並列コンパクションをしているときから発生した参照の追加と更新をアプリケーションスレッドを止めて最終確定します。これでGCが完了しました。

f:id:cybozuinsideout:20180527142636p:plain:w300

さて、GCの全体像を最後に眺めてみます。

コンカレントコンパクションのおかげで、アプリケーションスレッドの停止を減らしつつ、メモリのフラグメントも回避できているのが お分かりいただけたかと思います。

ZGC

さて、続きましてZGCの方に行きたいと思います。

f:id:cybozuinsideout:20180527142633p:plain:w300f:id:cybozuinsideout:20180527142629p:plain:w300

ZGCですが、Oracleで開発されたGCです。数TBのヒープでもGCによる停止時間が多くないという触れ込みです。 こちらもZGCを利用するにはバックポートが必要です。

f:id:cybozuinsideout:20180527142625p:plain:w300f:id:cybozuinsideout:20180527142622p:plain:w300

ちょっとShenandoah GCでお腹いっぱいの方もいらっしゃる方もいらっしゃるかと思いますが…

基本的なコンセプトは、ShenandoahGCと同じなので、安心してください。 世代管理型のメモリ管理をせず、リージョン型のメモリ管理です。そして、並列コンパクションをします。

ZGCの大きな特徴としてLinux 64bit OSでしか今のところ利用できません。Javaの世界観からするとロックな存在ですね。 ZGC特有の特徴ですが、おおきくは3つほどあります。あとから詳しく説明していきます。

カラーポインタ、仮想メモリの有効活用、最後にフォワーディング・テーブルです。

f:id:cybozuinsideout:20180527142616p:plain:w300

一つずつ見ていきましょう。まずはカラーポインタです。

ShenandoahGCのときもオブジェクトが待避済みかどうかを判定するのがキモでした。

ZGCでは、オブジェクトの状態をカラーとして表現するわけです。 マーク済み0、マーク済み1、オブジェクト待避済みと3つのカラーを持っています。

マークはマーキングフェーズで利用するのですが、0と1の二種類が存在する理由はあとできっちり回収しますのでお待ち下さい。

f:id:cybozuinsideout:20180527142612p:plain:w300

カラーポインタの色の管理ですが、64bitのメモリアドレスをフル活用します。特定のアドレスのフラグを立てて管理します。

オブジェクトが配置されている位置は下位42ビットを利用しています。そして、4ビットを使ってオブジェクトの状態を管理します

f:id:cybozuinsideout:20180527142608p:plain:w300

これを64bitのアドレス空間全体をみてみます。最大4TB分のヒープメモリは42ビットで表現されます。

43bitから上位4bitを使って、オブジェクトの状態を表現します。アドレスのカラーポインタのビットが立っていたり立たなかったりします。

64bitのアドレス空間をすべてつかうと128TBのメモリが理論上は必要になってきますがそんなマシンみたことないですね

f:id:cybozuinsideout:20180527142605p:plain:w300

見せかけの巨大メモリの正体は仮想メモリです。LinuxのOSに詳しくないと、想像しにくいかとおもいます。 最近Linuxのすばらしい入門書に仮想メモリの章があるので、興味がある方は是非購入していただければと思います。

f:id:cybozuinsideout:20180527142601p:plain:w300

さて、GC全体を眺めていきましょう

f:id:cybozuinsideout:20180527142557p:plain:w300f:id:cybozuinsideout:20180527142544p:plain:w300

アプリケーションスレッドを停止してRootから辿れるオブジェクトをマーキングしていきます。 次にアプリケーションと並列でRootからさらにオブジェクトの参照を辿っていきます。

f:id:cybozuinsideout:20180527142539p:plain:w300

並列マーキング中に発生したオブジェクトの参照の更新を更新して、ゴミオブジェクトの最終確定をします。

f:id:cybozuinsideout:20180527142535p:plain:w300f:id:cybozuinsideout:20180527142531p:plain:w300

ゴミの割合が多いリージョンがマーキングでわかるので、待避リージョンを決めます。 待避したオブジェクトには待避済みのマークを付けておきます。

待避すると決めたリージョンにはフォワーディングテーブルを作ります。

f:id:cybozuinsideout:20180527142528p:plain:w300

このフォワーディングテーブルですけれども、Shenandoah GCだとすべてのオブジェクトにヘッダをヘッダを付けているので、オーバーヘッドがあります。

ZGCでは、カラーポインタで待避済みかどうかは判定できるので退避先を参照するフォワーディングテーブルを作り待避後のオブジェクトの参照先を管理します。 要するに、メモリ節約したいんですね。

f:id:cybozuinsideout:20180527142521p:plain:w300

実はこれでGCは終わりなんですが、参照の更新が終わってません。

f:id:cybozuinsideout:20180527142517p:plain:w300f:id:cybozuinsideout:20180527142513p:plain:w300

GCのサイクルを全体で眺めてみましょう。並列コンパクションまではみました。 参照の付け替えですが、2週目のマーキングフェーズで一緒にやります。図のように、マーキングと参照の付替えがオーバラップします。

f:id:cybozuinsideout:20180527142509p:plain:w300

そのため、ZGCではConcurrent-Markは厳密には正しくないです。正しくはCuncurrent-Mark/Cuncurrent-Remarkなのです。

参照の付替えフェーズを別途設けずにオーバーラップすることでオブジェクトの参照をたどる回数を節約できるんですね。

ただ、こうすると前のGCサイクルでマーキングされたのか?今のGCサイクルでマーキングされたのか?判断がつかなくなります。 これを見分けるために、マーク用に定義されたカラーポインタが2個(mark0/mark1)存在しています。

f:id:cybozuinsideout:20180527142505p:plain:w300f:id:cybozuinsideout:20180527142501p:plain:w300

Cuncurrent Mark/Remapのフェーズを見てみますと前のGCサイクルとは違う色でマーキングをしていきます。

そうすると、前のGCサイクルでマークされたか、新しく参照されてマークされていないオブジェクトの判断が カラーポインタからできます。その結果をもとに、マーキングし直したり、オブジェクトを待避したりします。

リージョンが空にできました。これでZGCの説明はおしまいです。

Epsilon GC

f:id:cybozuinsideout:20180527142458p:plain:w300

最後にEpsilon GCです。

f:id:cybozuinsideout:20180527142454p:plain:w300

アプリケーションスレッドの停止をしないCPUの負荷がほとんどないGCの時間は限りなく0に近いというGCになっております。

f:id:cybozuinsideout:20180527142450p:plain:w300f:id:cybozuinsideout:20180527142447p:plain:w300

そんな夢みたいな話あるのかと思うかもしれません。そんなGCがあるんです。

なぜならこのGCはなにもしないGCだからです。

f:id:cybozuinsideout:20180527151344p:plain:w300f:id:cybozuinsideout:20180527151340p:plain:w300

オチが付いたところで、種を明かしますと

JVM開発目的のGCです。 パフォーマンス測定でGCによる性能劣化を排除するために作られました。ヒープが埋まるとOutOfMemoryErrorが発生します。

本番環境では使わないようにしてください。

まとめ

f:id:cybozuinsideout:20180527151337p:plain:w300

現在、開発中の巨大ヒープ・多コアが前提のアプリケーション用GCを紹介しました。 運用中のアプリケーションのGCによる停止時間が問題になっている場合、将来的に検討の余地があるかもしれません。

Linux 64 bit OSならZGC。それ以外ならSheandoah GCが利用できます。Epsilon GCは何もしないGCです。

ご清聴ありがとうございました。

最後に

最後まで読んでいただきありがとうございます!ざっくり理解していただけたでしょうか?

実際に生の発表を聞きに来てくださった方もありがとうございました!

参考URL

 

ベトナムの新オフィスへ行ってきました!

こんにちは。Xin chào! 東京品質保証部の青田です。Cybozu Vietnamへ出張してきたので、そのオフィスを紹介しつつ、どのような感じで一緒に働いているかを紹介したいと思います。

Cybozu Vietnam とは

サイボウズは国内外にいくつかの開発拠点を持っています。ベトナム拠点は2006年にホーチミン市に設立し、2009年独立法人化、かれこれ10年ほどGaroonや周辺製品の開発・試験を担っています。増員に伴ってオフィスを移転して、増床工事を進めていました。

Garoonチームは日本・上海・ベトナムの各拠点にメンバーがいて、昨年からはスクラム開発を導入しています。そのあたりの苦労話は色々あり、先日JaSSTというイベントでスクラムマスターが講演していました。

blog.cybozu.io

製品担当チームとは別にTest Engineering TeamProduct Security Incident Response Teamがあります。これらも拠点をまたいで活動しているチームです。

どのチームも普段はグループウェアやTV会議を利用して仕事を進めています。メンバーの出張はわりと頻繁に行っていて、チームによってペースは異なりますが、四半期ごとに行ったり来たりしているような感じです。仕事仲間とはリアルに顔を合わせておこう、というスタンスですね。私も今回そういう理由で、毎週定例会議を持っているメンバーに会いに行きました。ついでに工事が完了した新フロアを見物してきた次第です。

オフィス内

Cybozu VietnamはHo Chi Minh CityにあるCentre Pointというビルにあります。空港からタクシーで10分ほど、結構交通量が多い市街地。

エントランス

f:id:cybozuinsideout:20180522170212j:plain:w400

会議室

増床した結果、会議室は質量ともに充実していました。多くは名称・内装がベトナムの名所由来で、個人的にはHang Sơn ĐoòngをモチーフとしたSON DOONGという会議室がお気に入り。なぜか和風の会議室もありました。

f:id:cybozuinsideout:20180522171537j:plain:w300 f:id:cybozuinsideout:20180522171604j:plain:w300

通路側からは、会議室内に設置されているカンバンがちらっと見えたり。

f:id:cybozuinsideout:20180522172920j:plain:w300

イベントスペース

50人超を収容できるイベントスペースもあります。写真は開発本部長の佐藤がベトナムメンバー向けに方針説明会を開催しているところです。

f:id:cybozuinsideout:20180522172146j:plain:w300

イベントスペースの一角にはくつろげる場所やキッチンが用意されています。

f:id:cybozuinsideout:20180522172602j:plain:w300 f:id:cybozuinsideout:20180522174344j:plain:w300

開発本部長による情報の共有 & 質問会

ベトナムの開発・QAに対して、開発本部長が

  • 進行中のプロジェクト
  • DevOps、アジャイル(スクラム)など開発体制

について共有する会がありました。

f:id:cybozuinsideout:20180522173302j:plain:w300 f:id:cybozuinsideout:20180522173529j:plain:w300

リードタイムの短縮という目標、我々が抱えている課題、目指したいチーム体制といったあたりについての説明があり、参加者からも活発な質問・意見が出ていました。 徐々に改善を進めてきてはいますが、未だにTest Pyramidは逆三角形であり、今後も開発とQAが協力して安定感のあるピラミッドにしていきたいという話も強調していました。そのためにテスト自動化を推し進めていったり、Dev/QA/Opsの職能間の垣根を無くしてゆく努力が必要で、各拠点で強みを生かして協力する必要がありますね。

規模や扱う内容は様々ですが、海外拠点に赴いて情報を共有・議論するのは当社における常套手段です。オンラインで情報共有ができるサービスを開発している会社としては、ちょっと不思議な気もしますが、強いチームを作る際には対面の方が良いのかもしれません。

さいごに

品質保証部では、新卒・キャリア採用を行っています。

あなたも一緒にサイボウズで品質保証活動を行ってみませんか?

www.wantedly.com