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

 

社内ハッカソンを開催しました

f:id:cybozuinsideout:20181102154637j:plain

こんにちは!開発部の刈川です。 サイボウズでは毎年社内でハッカソンを開催しているのですが、先日開催したので簡単に内容をご紹介したいと思います!

概要

f:id:cybozuinsideout:20181102155726p:plain

今年は東京、松山、大阪、ベトナムの4拠点と各々の自宅(在宅勤務)を含めた55名の方に参加してもらいました。 期間は3日間でテーマは自由となっています。3日目に最終発表会を行い、その中から投票で4つの賞を決めました。 賞は以下のとおりです。

  • 大賞
  • 技術(チャレンジ)賞
  • アイデア賞
  • デザイン賞

成果物をいくつかご紹介します。

Terraform-provider-kintone(大賞)

大賞はTerraform-provider-kintoneでした。これはTerraformというインフラ構成管理ツールのkintone用のプラグインです。 嬉しいポイントをざっくりいうと『いままで画面をポチポチやって作るしかなかったkintoneのアプリケーションをコードベースで管理/デプロイすることができる』ということです。kintoneもterraformも知らない方には「?」という感じですが、これができるようになると様々なことが自動化できて、kintoneが更に便利になるのです。 www.terraform.io

ぷよぷよのプレイ動画を解析して棋譜を生成(技術賞)

f:id:cybozuinsideout:20181130163241p:plain
©SEGA
その名の通り、ぷよぷよのプレイ動画から棋譜を生成して分析するためのツールです。 予め用意したパターン画像からぷよの画像の差分をとって色を判定したり、ツモった時や連鎖が発生したタイミングをグラフで分析したりと技術の無駄遣い感がものすごいのですが、いかにもハッカソンらしいチャレンジが評価されました。
f:id:cybozuinsideout:20181130163731p:plain
ぷよぷよってこんなゲームなの…?

kintone-VR

kintone-VRは、Oculus Goとkintoneを連携してVR空間にkintone上のコメントを描画するシステムです。 ハッカソンの成果発表では実況スレッドを利用しており、デモでは実際にこのシステムを見た反響のコメントがVR空間に描画されていました。

Oculus Goでわいわい

開催にあたって

社内ハッカソンは毎年開催しているのですが、年ごとにテーマを設けています。 たとえば「コネクト」がテーマの回では、普段の業務では関わりのない人同士を運営側でランダムにチーム分けしてハッカソンに臨んでもらいました。こうすることで今まで知らなかったノウハウの共有や、その人がどういう技術が得意だということが分かったりと、ハッカソンの成果物以外の副産物としてのメリットも生まれます。

参加者同士でランチ        在宅でハッカソンしてる人

おわりに

最近サイボウズではモブプログラミングが流行しているので、今度は合宿形式×モブプログラミングで企画をする予定です。 開催したらこちらでご紹介したいと思います。それではまた!

 

KubeCon + CloudNativeCon North America 2018 現地レポート 3日目

こんにちは、Necoプロジェクトのsatです。カンファレンス最終日、3日目のレポートです。

0日目から2日目のレポートはこちらです。

blog.cybozu.io

blog.cybozu.io

blog.cybozu.io

2日目までは執筆者各人がその日に参加したセッションの中からいくつか面白かったものを選んで書くというスタイルでしたが、最終日の今日は少し毛色を変えて1日目と3日目に合計4つのセッションがあったRookというソフトウェアを集中的に紹介したいと思います。Rookとは分散ストレージソフトウェアの一つであるCephをkubernetesによって管理するためのオーケストレーターです。

Cephについてご存じないかたは、本記事を見る前にCephの概要について述べた以下の記事をごらんください。

blog.cybozu.io

Intro: Rook - Jared Watts, Upbound

これはRookの基礎について紹介するセッションでした。

Rookは前述の通りkubernetesを使ってCephを管理するソフトウェアです。RookはまたCNCFのincubating level(孵化段階の)プロジェクトでもあります。

github.com

kubernetesはボリュームプラグインという仕組みによってアプリケーションに提供する永続ストレージのプロバイダを追加できます。Cephもそのバックエンドの一つとして利用できます。ただし、そのためにはユーザが自分自身でCephクラスタを構築、管理する必要があります。kubernetesを拡張してこれらの面倒事を自動管理してくれるソフトウェアがRookです。

f:id:cybozuinsideout:20181214141409j:plain

Rookが提供する機能は単なるクラスタを自動構築、管理だけではありません。Cephは通常クラスタを管理するためにユーザがコマンドを発行する必要があります。これに対してRookではkubernetesが扱う各種リソースと同様にCephクラスタを宣言的に扱えます。例えばCephクラスタを定義するyamlファイルにモニタの数を3つと書いておけば、モニタの数が3つであるクラスタを自動的に構築し、かつ、モニタのうちの一つがダウンしたとしても自動的にモニタの数が3に戻るようにRookがよきにはからってくれます。この宣言的な管理を自前で実装するのではなくkubernetesに任せるというのがRookの巧みなところです。

f:id:cybozuinsideout:20181214141413j:plain

セッションの後半にはRookを使って実際にCephクラスタを構築するデモがありました。Cephのクラスタを幾度となく構築した経験がある筆者から見ると、「なんて楽なんだ」というのが率直な感想です。kubernetesに短いyamlファイルを投入するだけでモニタやOSDなどのCephの各コンポーネントがPodとして次々に立ち上り、次第にCephクラスタが出来上がってゆく様は圧巻でした。

Deep Dive: Rook - Travis Nielsen, Red Hat

このセッションは前述の"Intro: Rook"に比べてRookのさらに詳細について扱うものでした。

前半はRookにおけるCephの各種リソースの定義についての話でした。ここではそのうちの一部について紹介いたします。

  • Cephクラスタを示すリソース: 指定されたバージョンのCephを使ってクラスタを作る。この定義を変更すればCephを自動的にアップグレードしてくれる。Rookのバージョンも同様に管理できる
  • OSDを示すリソース: どのノードのどのストレージデバイスをOSDとして提供するかを定義できる。それに加えてストレージデバイスが並列アクセスが高速なNVMe SSDだった場合に、デバイスごとに複数のOSDを定義してI/Oを高速化させられる

今後もいろいろ定義できる項目が増えていくことでしょう。

後半にはいくつかのデモがありました。たとえばRookによってCephの一つ前の安定版(コードネームはLuminous)から最新の安定版(コードネームはmimic)にアップグレードするといったものがありました。クラスタを定義するyamlファイルの中のCephのバージョンに相当する部分を一か所書き換えるだけでアップグレードができるというのは筆者にとっては驚きでした。

Adding a New Storage Provider to Rook - Jared Watts, Upbound

このセッションはRookに新しいストレージプロバイダを追加する方法についてのものでした。

ここまでCephの話ばかりしていましたが、実はRookはCeph以外のストレージソフトウェアも永続ストレージのプロバイダとして使えるようにするためのフレームワークを持っています。すでに現在NFS, Cassandra, CockroachDBなどをサポートしています。ソースコードを見たところ、現在のRookの主たるプロバイダはあくまでCephであり、残りのストレージソフトウェアは一部の機能しか実装していない評価版のような位置づけのようです。たとえばストレージプロバイダのAPIのバージョンはCephが先月末に唯一最初の安定版といえるv1になった以外はalpha版扱いです。

本セッションでは既に取り込まれているMinioのプロバイダを例に、プロバイダを追加するにはkubernetesにどのようなリソースを定義してどのようなコードを書けばいいかということを紹介していました。個人的にはCeph以外のプロバイダを使うことは無いと思いますが、開発全体が活発で、かつ、個々のプロバイダがRook本体と独立して開発できるのはいいことだと思います。

Meet the Maintainer: Rook - Jared Watts, Upbound

これはRookに興味のある参加者がRookのメンテナに直接質問できるセッションです。

筆者は本イベントに参加する前にRookについて興味を持っていたため、その動向を追ってきました。それに加えて各種Rookのセッションを見たことによって、いくつかの疑問が湧きました。せっかくなので本セッションにおいてそれらについてメンテナに質問してみました。

  • Q: 現在RookはRADOSオブジェクトのレプリカをそれぞれ同じノードに置かないように設定できるが、それ以外の設定はできない。私が作ろうとしているCephクラスタにおいては各レプリカを別ラックに置きたいと思っている。直近でこのような設定をできるようにする予定はあるか
  • A: 今後しばらくはRookによってクラスタを組んだ後にRookを介さずに直接Cephを操作することによってそのようなことを実現するしかない。将来的にはサポートするかもしれない。

  • Q: 最新版のv0.9までは毎回のように非互換が発生していた。これではプロダクション環境でRookを使いにくい。今後しばらくはこのような状況が続くと考えてよいか

  • A: 今後は非互換を発生させないようにする見込み。もちろんRookに閉じた話ではなくCephに非互換が発生した場合はこの限りではない

  • Q: Cephには大量のリバランス処理をきっかけとしてネットワークの帯域を使い果たし、一切クラスタにアクセスできなくなるという問題が起こりうる。実際そのようなケースをこれまでにいくつか見てきた。この問題に対処するための帯域制御機能をRookに実装する予定はあるか

  • A: 今のところはそのような帯域制御はユーザ自身がするしかない。Rookがそのような仕組みを用意することはやろうと思えばできるだろうが、そのような機能を追加する予定は今のところ無い

知りたいことにすべて丁寧に回答してもらえたので非常に満足できたセッションでした。

ここで余談をひとつ。本イベントは多くのセッションについてスライドが公開されていたり、ものによっては発表時の動画が公開されることすらあります。それでも現地に行く価値はどこにあるのでしょうか。それは上記のような質疑を含む参加者同士の対話です。みなさまもこの手のイベントに参加する際はご自身の持つ課題についてメンテナを含む他の参加者と議論してみてください。イベントがもっと楽しくなりますよ。

Rookについての現在の印象

Rookは宣言的にCephクラスタを扱えること、および、そのために既にある程度成熟しているkubernetesを利用しているという2つの点において、なかなか筋がいいソフトウェアに見えます。現在はまだ粗削りですが、Red Hat社やQuantum社などの企業のエンジニアやホビープログラマなどの多様な人々によって活発に開発が進んでいることより、将来的には「kubernetesでCephを使うのならばRookを使うのが常識」という状況になっても不思議ではありません。今後も引き続き開発動向を追っていく予定です。

KubeCon全体の総評

とにかく人数が多くて熱のこもったイベントだったというのが全体の印象です。筆者はこれまでOpen Source SummitなどのOSSに関する国際イベントにいくつも出てきましたが、八千人もの大人数が参加する規模ものはかつて無かったです。世間のコンテナ熱、kubernetes熱を見るに、次回以降もますます盛り上がっていくことでしょう。

もちろん我々は単に驚いて圧倒されていたわけではなく、得るものがたくさんありました。ここではそのうちの1つを紹介いたします。我々はkubernetesの最新、かつ深い知識を得るために本イベントにやってきました。ところが、幸か不幸かレベルが高いと記載されているセッションに参加しても既に知っている内容が多かったです。このため、次回以降は参加するだけではなく、自分たちのセッションを持つことによって我々の知見をkubernetesのコミュニティに共有することが一つの目標になりました。

これまで4日にわたってKubeCon + CloudNativeCon North America 2018の様子をお届けしてまいりましたが、これにてすべて終了です。ここまで読んでくださった方に感謝いたします。我々のレポートがみなさんにとって何かしら役に立つものであれば幸いです。

 

QAエンジニアのAgile Testing vol.3

こんにちは!松山品質保証部の北地です。社内で「セキュリティテスト」をテーマにパネルディスカッションを開催しました。その様子と得られた気づきをご紹介します。 f:id:cybozuinsideout:20181205170314j:plain

テーマ選定やイベント開催の経緯についてはこちらにまとめています。

QAエンジニア(以下、QA)をメインターゲットとして企画した本イベントですが、プログラマー(以下、PG)やスクラムマスター、プロダクトオーナーにも興味を持ってもらえて、総勢約40名が集まりました!

パネラーに投げかけた質問

パネラーにはサイボウズ製品の品質保証責任者とセキュリティテストを担当するPSIRT(Product Security Incident Response Team の略)を招集しました。パネラーに向けて以下のような質問を投げかけディスカッションしていただきました。(一部抜粋)

  • セキュリティテストの実施単位は?
  • PSIRTは試験計画をどのように立案しているの?
  • 開発チームはいつごろ、どのような内容でPSIRTに検証を依頼しているの?
  • 社外から脆弱性の報告があった場合、対応フローは?
  • PSIRTは開発チームのスクラムイベントに参加している?
  • PSIRTが開発チームのスクラムイベントに参加する必要はある?

f:id:cybozuinsideout:20181113153705j:plain
東京でのパネルディスカッションの様子

ディスカッションにより気づいたこと

上記のような質問に対してディスカッションを進めることで以下の気づきがありました。

  • セキュリティテストの実施タイミング
    "開発完了後に一括して実施"するチームと"スプリント単位で実施"するチームがありました。
    前者は、PGとPSIRTの間をQAが仲介しており、 変更が発生した際のPSIRTとのやり取りの手間がかかるために、"スプリント単位での実施"は困難とのことでした。
    一方、後者は、PGとPSIRTメンバーが直にやり取りをすることで効率化しているようでした。

  • PSIRTにとっての、スクラムイベントに参加するメリット
    要件を早めにキャッチアップできたり、PGとのコミュニケーションがスムーズになったという意見が多かったです。

  • 振り返り
    PSIRTは内部で振り返りを実施しており、開発チームの振り返りには参加していませんでした。しかし、このディスカッションを通して開発チームの振り返りに PSIRTが参加することのメリットはありそうだという意見が出ました。

  • 設計段階からの参加
    今後の課題として、PSIRTがリリース前にセキュリティ観点で品質を作り込めることが挙げられました。

f:id:cybozuinsideout:20181205170317j:plain
松山オフィスからのリモート参加の様子

イベントを振り返ってみて

SPITzメンバー及びパネラーを交えて振り返りを行いました。Agile Testing活動のコンセプト(※)を実感できたか、という点を振り返ってもらった結果、「少し実感できた/あまり実感できなかった」という意見が大半でした(以下、参加者のコメント)。

〇少し実感できた

  • 各チームのセキュリティテストのプロセスの流れはほぼ同じだったが、ほかのチームの取り組み方について知ることはできて、興味深かった。
  • 今まで知らなかった他製品のプロセスを知れたことが単純に面白かった(参考になった)。

〇あまり実感できなかった

  • 今すぐ何か取り入れたいということはなかった。
  • 自分たちのチームではやっていない取り組みの話題は出ていたが、具体的な話をその場で質問できなかったため、壇上のメンバー同士で質問をする時間をもうけてもよかったかもしれない。

総じて「他製品のチームのプロセスへの理解が深まったものの、次のアクションにつなげるための効果としては弱かった」といった印象です。次回の活動では今回の弱点を改善していきます!

(※)製品QAメンバーに「他のチームのAgile Testing情報参考になる。自分たちもこれから取り入れてみよう!」と言ってもらうこと。

次回予告

「理想のAgile Testing ワークショップ 」を開催する予定です。レポートにご期待ください!

We are hiring!!

サイボウズでは「日々の仕事をカイゼンしたい」「いろんな人と繋がって学び合いたい」というカイゼン意欲をもった方がチャレンジできる環境があります。

キャリア採用 QAエンジニア | サイボウズ 採用情報(新卒・キャリア)
キャリア採用 QAエンジニア(ミドルウェア) | サイボウズ 採用情報(新卒・キャリア)
キャリア採用 テストエンジニア | サイボウズ 採用情報(新卒・キャリア)

ぜひ私たちと一緒に働きましょう!

 

KubeCon + CloudNativeCon North America 2018 現地レポート 2日目

こんにちは、Necoプロジェクトの森本です。 カンファレンス2日目のレポートです。 ほかの日程のレポートはこちら。

blog.cybozu.io

blog.cybozu.io

blog.cybozu.io

トピックを絞って丸一日議論した0日目Co-Located Event、全参加者を迎えての基調講演から始まった1日目に続き、2日目となります。 日程の組み方が、1日目はビギナー向けを多めとし、そこから次第にマニアックな内容に向かう構成となっているようです。 どんなディープな議論となるか、楽しみ楽しみ。

f:id:cybozuinsideout:20181213155915j:plain
基調講演の会場。とにかく大人数。

Keynote: Kubernetes Project Update

本日も基調講演から始まります。 まずはKubernetesの普及度合いの説明から。 ここまでにInnovatorsからEarly Adoptersへと順調に普及が進み、今はEarly Majorityに手を伸ばしています。 これまでは新機能の追加でワイワイやっていたけれども、ここからの段階では安定して動くこと・一貫した動作をすることが重視されるようになります。 ちょっと退屈なフェーズに入ったように見えるかもしれませんが、ここからが大切なところ。 これからもOpen StandardとExtensibilityという二本の柱を守って進めていきましょう、という呼びかけでした。 Kubernetesの利用者に対しては、システムが大きく変わってしまってそれまでの投資が無駄になる、なんてことはないんだよと安心を与えるような呼びかけとなっていました。

Keynote: Save Yourselves!

こちらのお話はセキュリティに関してのもので、発表者は会議の司会進行役も務めるLiz Riceさん。 この人が登壇するだけで会場から歓声が上がるという人気者です。 まずは基本的な話として、そこらに転がっているようなマニフェスト(サービスの構成情報)を適当に使っちゃうと大変なことになるよ、ということで実演してみせます。 ネットから落としたYAMLファイルをkubectl applyしてデモの画面に表示されたのは……"all your pod are belong to us"。 これは冗談としても、野良マニフェストを使うとadmin権限でやりたい放題の状態となってしまうので注意が必要です。 やりたい放題を防ぐ仕組みとして、APIサーバまでの間にAdmission Controllerを挟んで「このリソースにこの操作はやっていい、この操作はやっては駄目」等々細かく判断させる、あるいはそれをもっと簡便にOpen Policy Agentのポリシーとして記載する、といった対策が紹介されていました。 最近だと不正に得た計算パワーを仮想通貨のマイニングに悪用するというのが定番らしく、気を付けたいところですね。

Keynote: Developing Kubernetes Services at Airbnb Scale

さらに基調講演から、近来話題となっているAirbnb社さんにおいてmicroservicesをどう取り扱っているかというお話です。 サービスデリバリのサイクルを細かく速く回してサービスを提供したい、モノリスなサービスは大規模化が進んでいてまったくデプロイを加速できない、ということでKubernetesでのmicroservicesという形でサービス提供を進めているとのことです。 しかし1,000を超えるチーム(すごい規模ですね)がそれぞれmicroservicesを取り扱おうとすると、効率化を進めなければいけません。 まずKubernetesで問題となるのは、使い始めたときに誰もが感じることかと思いますが、いくつもいくつもYAMLファイルが必要となること。 1つのサービスのために10個以上のファイルを用意し、しかもどのサービスでも似たような内容となるファイルを毎回用意する必要があります。 Kubernetes boilerplate! (決まり文句!)でウンザリだということで、これをテンプレートから生成するようにします。 さらに、サービスごとにenvironment/namespaceを区切るわけですが、区切った際の名付け方を標準化しておきます。 これにより、同じことを何度も書くという無駄な手間を省き、どの環境でも標準化された方法で操作対象を指定できるようになります。 このほか、CI/CDを簡単にできるように、特に開発者がそれぞれでできるように仕組みを用意する等、実際に開発・運用していて詰まったんだろうなというところを丹念に潰しているように思えました。 開発者の試行錯誤が見えてくるような発表でした。

前夜の爆弾

ここまで基調講演を見てきましたが、実は前夜に爆弾が投下されていたのでした。

身も蓋もないと言いますか何と言いますか。 これを受けてかどうか、今日の基調講演はそう悪くなかったと思うのです。 徹夜で必死に直した方もいたのでしょうか……。

f:id:cybozuinsideout:20181213160946j:plain
唐突なお土産コーナー。各プロジェクトのマスコット人形を売っていたりします。

Building Container Images on Your Kubernetes Cluster with Knative Build

この後は各部屋に分かれてのセッションです。 CIのためにビルドシステムを別途用意するのは手間だよね、いつものKubernetesクラスタの中でビルドを扱いたいよね、ということで、Knative Buildによりビルド手順を表現し、Kubernetesクラスタで実行するというものです。 Knative (ケイネイティブと読まれていました)はGoogleが推進しているプラットフォームで、サーバレスなアプリを手軽に書いて、後のこと(ビルドだのデプロイだのモニタリングだの)はお任せというものです。 ここでは、CRD (Custom Resource Definition; 拡張APIのためのデータ構造)を用いてビルドプロセスをモデル化し、ビルド手順のステップを「このコンテナイメージでこのコマンド(ビルドだったりテストだったり)を実行する」という形で記述して与えていました。 私たちNecoプロジェクトでもCircleCIの設定でそのようなビルドステップを記述していますが、より統一的・汎用的に扱えるようになるのでしょう。

So You Want to Run Vault in Kubernetes?

HashiCorp社さんが公開している機密管理ツールVaultを、Kubernetesクラスタで安全に動かすにはどうするかという、ベストプラクティスの発表です。 Necoプロジェクトでもちょうど、Kubernetesクラスタの構築の中でVaultをセットアップして管理基盤に据えています。 さて自分たちのやり方でおかしなところはなかったかなと発表を見に行きました。 その結果ですが、API利用は必ずTLSを用いましょうとか、ロードバランシングはL7ではなくL4としてTLSの終端はVaultが握るようにしましょうとか、IPC_LOCKを指定してページアウトを防ぎましょうとか、まったくもってそのとおり、私たちもそのように気を付けてるよ、というものでした。 期待以上でも期待外れでもなく、期待どおりというところ。 まあ、それで良かったのでしょうね。

プロジェクトメンバーで振り返ったところ、実はこれ以外のセッションでも似たような問題(期待以上ではない)が発生していました。 多くの参加者を対象としたセッションではそこまで深い情報は出てこないため、自分たちがこれまでに分け入ったコンポーネントについてはあまり新たな情報は得られないのでした。 各コンポーネントのメンテナの方とお話しできるよ、という時間帯も設けられていますので、深く突っ込みたい場合はそこに突撃するのが良いのでしょう。 相当のコミュニケーション能力、というか英語力が試されますが……。

f:id:cybozuinsideout:20181213161401j:plain
求職・求人コーナー。定番の光景です。

All Attendee Party!!!

夕方になりました、なんだかみんなソワソワし始めました。 本日は締めの基調講演はなく、会場から場所を移してパーティーなのです! シアトル名物のSpace Needleタワーに上ったり、美術館や博物館が立ち並ぶエリアを散策したり、楽しみですね!

というところなのですが、残念、これもシアトル名物の冬の雨に降られてしまいました……。 今日は朝から青空も見えていて珍しく落ち着いた天気だったのですが、狙いすましたかのような雨です。 しかも8,000人がシャトルバスに乗るための行列。 人、人、人。

結局パーティーは諦め、近くのレストランでおいしいものを食べて退散しましたとさ。 めでたしめでたし。

ブログの最後は素敵な写真で飾ろうと思っていたのですがそれもおじゃんとなりました。 明日 3日目の現地レポートをもって、埋め合わせとさせていただきたく思います。 どうかお楽しみに。

 

分散ストレージソフトウェアCephとは

はじめに

こんにちは、Necoプロジェクトのsatです。Necoプロジェクトではサイボウズのクラウド基盤であるcybozu.comのストレージに関する様々な要件を満たすために分散ストレージソフトウェアCephを導入する予定です。本記事ではCephとは何者かについて紹介いたします。Cephが持っている機能は膨大な数にのぼるため、ここでは一部の機能に絞って紹介したいと思います。

概要

Cephはオープンソースの分散ストレージソフトウェアです。2004年以前からカリフォルニア大学で開発され、2006年にオープンソース化されました。現在ではRed Hat社をはじめとするさまざまな企業、あるいは個人によって活発に開発されています。Cephは例えばOpenStack のストレージ機能(Cinder, Swift, やGlanceなど)の選択肢の1つとして使われています。

Cephは複数台のマシン上のストレージデバイスを束ねて一つのストレージプールを作り、そこからPOSIX-like*1なブロックデバイス(RBD)、S3やSwift互換インターフェースを持つオブジェクトストレージ(RADOSGW)、ファイルシステム(CephFS)を切り出してユーザに提供します。

f:id:cybozuinsideout:20181213061217j:plain
ceph

ここで用語をいくつか定義しておくと、CephにおいてはCephクラスタを構成する個々のマシンをノード、その中の個々のストレージデバイス(ないしパーティション)をObject Storage Device(OSD)と呼びます。上図においては円筒型の図形がそれに対応します。

なおNecoではCephFSは使わずにRBDとRADOSGWだけを使う予定なので、これ以降ファイルシステムについては述べません。

データの冗長化(RADOS)

Cephはストレージプール上にReliable Autonomic Distributed Object Store Object(RADOS)というオブジェクトストレージシステム*2を持っており、RBDやRADOSGWなどはRADOSオブジェクトと呼ばれるRADOS上の個々のオブジェクトの塊として提供されます。個々のRADOSオブジェクトは通常複数のレプリカが作成され、それぞれ別のOSDに保存することによってデータの冗長化を実現しています。以下レプリカ数3のRBDを示した図です。

f:id:cybozuinsideout:20181213061221j:plain
rados

データのレプリカを持つことによって個々のOSDに問題が発生したときもデータは失われず、運用が継続できます。それだけではなく、レプリカ数が2なら運用を継続するものの、1になったらそのオブジェクトには冗長度が2以上に回復(冗長度を回復させるリバランス処理については後述)するまでアクセスを失敗させることもできます。

データ配置位置の決定方法(CRUSH)

個々のRADOSオブジェクトのレプリカをどのOSDに配置すべきかはどのようにして決定するのでしょうか。CephにおいてはControlled Replication Under Scalable Hashing(CRUSH)というアルゴリズムを用いて、RADOSオブジェクトの名前のハッシュ値、および現在生存しているOSDのリストをもとにRADOSオブジェクトの配置位置を計算によって求められます。これによってHadoopのNameNodeのような「どのデータをどこに保存すべきか」ということを保存した巨大な管理データを持つ必要がありません。それに加えてI/Oが発生するごとにそのようなデータにアクセスする必要がないので、高速なI/Oが期待できます。

CRUSHはOSDの物理的な位置を考慮してデータを配置するルールを設定できます。具体的には、あるRADOSオブジェクトをすべてのOSDの間でランダムに配置する場合を考えると、すべてのレプリカが同じノード内のOSDに配置されてしまって、1つのノードに問題が発生しただけで当該データにアクセスできなくなるということが考えられます。このような状況を避けるために、Cephでは「オブジェクトは同じノードには1レプリカしか持てない」というルールが決められます。

f:id:cybozuinsideout:20181213063927j:plain
rule

クラスタの管理方法(モニタ)

クラスタの状態は1つないし複数の奇数個のノード上に分散配置されたモニタという機能によって管理します。モニタが複数個存在することによって、たとえば1つのモニタが応答しなくなっただけでクラスタ全体が機能しなくなるというような状況が避けられます。

モニタは「クラスタ内にどのようなOSDがあって、どのOSDにはアクセス可能か」といった情報をまとめたCRUSH mapという(上記NameNodeなどに比べると)小さなデータを持っています。モニタおよびOSDの間では定期的に死活監視処理が動作しており、状況が変わるたびにCRUSH mapは更新されます。モニタ同士はPaxosという合意形成プロトコルを用いて通信し合うことによって、クライアントないしOSDと通信する際には常に最新のCRUSH mapを元に判断ができるようになっています。

クライアントがデータの書き込み要求を出すときは下図のような流れで実際のI/Oが動作します。

f:id:cybozuinsideout:20181213061322j:plain
write

クラスタの拡大

Cephは運用を止めることなく、いつでも新しいOSDをクラスタに登録することによって容量を拡大できます(縮小もできます)。OSDを足した場合にはCRUSH mapが更新され、リバランスと呼ばれるデータの移動が発生することによって、クラスタ内のデータの偏りを防ぎます。

セルフヒーリング

クラスタ内のノードがダウンするなどの理由によってOSDがクラスタから見えないという状態が長時間続くと、Cephは当該OSDはダウンしたものとみなしてCRUSH mapを更新します。ここでリバランス処理が動作して、ダウンしたOSDのデータは他のレプリカのデータをもとに別のOSDに移動することによってオペレータの介在なしに冗長度が自動回復します。ダウンしたノードが再びクラスタが認識すると、データは再びもとのOSDに戻ります

bit-rot耐性

bit-rotという言葉をご存じでしょうか。ストレージデバイス上のデータは、ソフトウェアにバグが無い場合にもデバイスの物理的な問題によってビットが反転してしまうなどの理由によって壊れてしまうことが稀にあります。これがbit-rotです。この問題の恐ろしいところは、何も対策をしていなければデータが破壊したことにユーザは気づかないということです。

Cephに数年前導入されたBlueStoreというストレージバックエンド*3を用いればこの問題を解決できます。BlueStoreにおいてはデータをOSDに保存する際に、データのチェックサムも同時に保存します。OSDからデータを読み出す際に読みだしたデータのチェックサムと保存しておいたチェックサムが一致しない場合はそのデータは壊れているものとみなします。このときレプリカが存在すれば自動的にレプリカから正しいデータを復元させられます。

おわりに

本記事はCephの概要について述べました。今後も本記事では書ききれなかった機能の紹介などについての記事を書く予定です。また、ここではCephの良い面だけ紹介しましたが、世の中に完全なソフトウェアはなく、Cephもまたその例外ではありません。今後Cephを使うにあたって克服しなければいけない課題(たとえば大量のリバランス処理によるネットワークの飽和)、およびNecoチームではそれをどのように解決するかについて紹介する記事を書く予定です。

最後になりますがNecoチームではCephおよび分散ストレージシステムを自動的に構築・管理するシステムの開発者を募集中です。ふるってご応募ください!

キャリア採用 インフラ刷新プロジェクト Neco 開発者 | サイボウズ 採用情報(新卒・キャリア)

www.wantedly.com

*1:POSIX互換ではない部分が一部あります

*2:RADOSはRADOSGWとは異なりS3やSwiftなどとの互換インターフェースは持ちません

*3:データをOSDに保存する際のフォーマット、およびそれを処理するアルゴリズムと考えてもらえればいいです