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

 

社内で「TE Cafe」を開催しました

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

私が所属するテストエンジニアリング(以下、TE)チームでは、年に数回、社内メンバー向けにTEの活動報告や取り組みを紹介する「TE Cafe」を開催しています。

f:id:cybozuinsideout:20180205162755p:plain:w200

TEについてはこちらの記事をご覧ください。 blog.cybozu.io

2018年最初のTE Cafeは東京オフィスで開催され、ベトナム・上海・松山拠点に中継、さらに海外拠点では同時通訳をしながら開催しました!

今回は、TE Cafeでの発表内容をいくつかご紹介します。

2017年の振り返りと2018年の目標

TEチームは「枠組みを超えて品質/生産性の向上に貢献する」をミッションとして活動しています。

2016年は、各プロダクトにヒアリングをし、抱えている問題点を洗い出しました。

2017年は、問題を解決するためのツールの開発、導入支援を行いました。

テストを自動化するフレームワークやツールの開発は進んだものの、導入できたプロダクトはごく一部に留まりました。

反省点として、これらのツールや、自動化の導入事例を社内にアウトプットする機会が少なく、社内でのTEの活動の認知度がまだまだ低いということが挙げられます。

そこで、2018年は2017年に引き続き、「アウトプットを増やす」という目標を掲げます。

f:id:cybozuinsideout:20180205160344p:plain

TEの活動を積極的に発信することで、TEが開発したツールをプロダクトで使ってもらい、品質や生産性向上の助けとなることを目指します。

また、社内に留まらず、このCybozu Inside Out のブログ等で、社外への情報発信も積極的に行うことにしました。

自動テスト共通基盤について

TEでは、自動テスト共通基盤(Test Common Base、以下TCB)という、サイボウズ製品に合った自動テストのフレームワーク・ツールを開発しています。

TCBを使うことで、プロダクト毎に異なる手法で行われているテスト自動化を共通化して、導入/教育コストの削減や、ナレッジの横展開ができることを目標としています。

TCBには様々な種類のツールがあり、これらについて紹介しました。

以下に書いているものはその一部です。

  • eslint-config-tcb: サイボウズのESLint共通ルールを自動テストのテストコードに適用できるツール。

  • tcb-cli: TCBを使ったテストのサンプルファイルとフォルダを作成できるコマンドラインツール。

f:id:cybozuinsideout:20180205161727p:plain

  • tcb-api-rest: REST APIをテストする時に利用するツール。APIの実行から、結果の判定までできる。

  • tcb-hook: 自動テストの結果をkintoneのアプリやスレッドに投稿することができるツール。テストが失敗した時のスクリーンショットを投稿することも可能。

  • tcb-lerning: TCBを使った自動テストのコーディング方法を学習することができるツール。

f:id:cybozuinsideout:20180205161744p:plain

スクラム開発に対応した継続的性能検証(Garoon編)

最近、サイボウズでは多くのプロダクトがスクラム開発を採用し始めました。Garoonチームもその一つです。

スクラム開発では、2~3週間のサイクルで、出荷可能な製品の機能を作る必要があります。出荷可能な機能とそのテストだけでなく、性能要件も重要となってきます。

今までは、複数スプリント経過後~リリース前に性能検証を実施していました。

原因の特定に時間を要するような性能劣化が発見された場合、リリース遅延のリスクがありました。

そこで、日々性能検証を実行できるように、継続的な性能検証の自動化に取り組みました。

f:id:cybozuinsideout:20180205162158p:plain

テスト環境の構築、テストデータの挿入、テストの実行はJenkinsとScaleBenchを使い、テスト結果の確認はGrafanaを使っています。

今後はGaroonだけでなく、他のプロダクトへの普及も視野に入れています。

さいごに

上記に書いたことは、2017年のTEの活動のごく一部となります。

ベトナムTE、上海TEと良いチームワークを発揮し、少しずつですがサイボウズにテスト自動化の文化を浸透させています。

今年は、昨年の活動の実績を糧に、社内外へのアウトプットを積極的に行い、プロダクトの品質向上/生産性向上という使命を果たしていきたいと思います。

We are hiring!

TEでは一緒に働いてくれる仲間を大募集中です!

 

React.js meetup #5 を開催しました

フロントエンドエキスパートチームの小林(@koba04)です。

2/1にReact.js meetup #5をサイボウズで開催しました。 当日は雪が降っていましたが、会場がいっぱいになるほどたくさんの人に集まって頂きましてありがとうございました。

https://reactjs-meetup.connpass.com/event/76375/

Contributing React! @koba04

最初に、まず私から「Contributing to React!」というタイトルで、Reactにコントリビュートする方法を紹介しました。

Reactにコントリビュートしようと思っても、コードが複雑でどうしていいのかわからないということもあると思います。 そのため、コントリビュートするための第一歩に必要な情報について紹介しました。

Reactでは、good first issueというラベル以外にも、タスクの難易度に対するDifficulty: mediumのようなラベルもあったり、誰かが取り組んでいるgood first issuegood first issue(taken)に変わったりと、コントリビュートしやすくするための取り組みが行われています。

また、コードに対するPull Requestを送る以外にも、ドキュメントに対する修正もコントリビュートの1つです。 英語で書く必要はありますが、足りないと感じたドキュメントをPull Requestすることもできます。

他にも、ドキュメントの翻訳を行うという形でのコントリビュートも可能です。 Reactのサイトでは、YarnやJestと同様にCrowdinを使った翻訳の仕組みがあることを紹介しました。

コードに対してコントリビュートしたいと思っても、Reactの複雑なコードベースをすぐに把握するのは難しいと思います。 Reactのサイトには、コントリビュートする人に対するドキュメントがあります。

これらのドキュメントを読んで、まずはgood first issueをやってみたり、不親切な警告メッセージがあればそれを修正したり、新しく警告を追加することはコードにコントリビュートする第一歩になります。

また別のトピックとして、v17で廃止されるライフサイクルメソッドと新しいContext APIについても、大きな変更であるため簡単に紹介しました。

f:id:cybozuinsideout:20180202175726j:plain

Static sites with create-react-app and Junctions @james_k_nelson

React ArmonyというReactを学ぶためのサイトを作っていたり、Junctionsというルーティングライブラリを作成されている@james_k_nelsonさんの発表は、 create-react-appから作成したアプリをJunctionsを使い、15分でブログにする内容でした。 ライブコーディング中心の内容で、個人的にライブコーディング見るのが好きなのでとても楽しめました。

Panel Discussion

というメンバーでパネルディスカッションしました。 多くの人がReactを使うときに悩む、サードパーティライブラリの選定やアニメーション、CSSについて、Redux、ルーティングについて話しました。 他にも、Reactを教えるときに難しいところやドメインロジックの置き場についても触れました。

実際にプロダクトを開発するときに、どのように考えてどうしているのかという話がたくさん聞けて、とても勉強になりました。

f:id:cybozuinsideout:20180202175741j:plain

LT

10 min ReactDOM Codebase Overview @malloc007

Reactのコードを読んでみたという内容のLTでした。 まぁ複雑ですよね...。

Redux のディレクトリ構成を考える @sottar_

Reduxを使ったアプリケーションのディレクトリ構造についてのLTでした。 Container ComponentとPresentational Componentの使いわけや、Action CreatorやReducerなどをどのように配置するのかというパターンについてのお話でした。 actionsとかreducersのような単位で分けることをRails-styleっていうんですね。

中大規模開発をReactで行う現場から伝えたいこと @mki_skt

規模の大きなフロントエンド開発の難しいところやそれをどのように解決していくのかというLTでした。 テストの必要性や共通Componentの管理方法、ライブラリのバージョン更新についてなど、放置しておくと破綻してしまう部分についての話で、Twitterでもツライという声で溢れていました。

まとめ

今回は天候を考慮して懇親会を事前に中止したのもあって、参加者同士で話す機会が取れませんでしたが、その分パネルディスカッションを長めにしたので参考になることが少しでもあれば嬉しいです。 次回に開催する際の参考のためにも、感想などあれば共有してもらえると嬉しいです。

サイボウズでは、フロントエンドに専門的に取り組みたいエンジニアも募集しています。 ご興味のある方は是非ご連絡ください。

また、関東以外でも積極的に採用を行っていますのでよろしくお願いします!

 

JMX で快適モニタリング環境を作ろう

こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。

今回は Java アプリケーションのモニタリング等で活躍する JMX について記します。JMX を用いれば、きめ細やかでかつ手軽にモニタリングすることができます。もちろんサイボウズが提供するクラウドサービス cybozu.com でも JMX を活用して日々モニタリングを行っています。

モニタリングの重要性については今さら言うまでもありません。一方で現実のモニタリングは何かと手間がかかったり属人化してしまったりすることがありがちです。JMX は銀の弾丸ではありませんが、少なくともメトリクスの収集・提供部分に関しては利便性を提供してくれます。JMX ユーザーが少しでも増えるよう、この記事で紹介させていただきます。

JMX とは

JMX とは Java Management Extensions の略称で、Java アプリケーションを管理するための仕様です。この JMX を用いることで Java アプリケーションの任意の項目を外部から取得したり設定できたりします。

特別な設定をしなくとも JMX を用いてヒープや GC の情報は取得できますし、また、既存の数多くのアプリケーションが JMX に対応しています。例えば Jetty や Tomcat、 Solr、 Elasticsearch、 Hadoop、 Cassandra 等々、それぞれがアプリケーションに応じた細やかなメトリクスを収集できるようになってます。同様に多くのモニタリングツールやサービスが JMX に対応しており、 Zabbix や Prometheus、 Datadog や Mackerel 等を使えばスムーズに JMX によるメトリクス収集を行えます。

今回は、任意のメトリクスを外部から取得するケース、つまり一般的なモニタリング用途での使い方について紹介します。例として、サーバーにやってきたリクエストの数を取得する JMX の例を作ってみます。

手順は下記の通りで、小さなコードでモニタリング出来ることを示したいと思います。

  1. 取得したいメトリクスに沿った MBean インターフェースを作る
  2. MBean を実装したクラスを作る
  3. 2. のクラスを MBeanServer に登録する
  4. メトリクスを取得可能な場所で値を設定する
  5. モニタリングシステムでモニタリング項目を取得する

MBean インターフェースを作ろう

まず始めに、MBean というインターフェースを作る必要があります。MBean(Management Bean) とは管理された Bean を意味し、ここではモニタリングに用いるオブジェクトということを表します。外部からアプリケーションの情報を取得する際はこの MBean を介します。

作成したインターフェース名のサフィックスの MBean は省略できないので注意してください。今回は RequestMonitorMBean という名前でインターフェースを作ります。インターフェースには、JMX で取得したい項目を記述します。

public interface RequestMonitorMBean {
    long getRequestCount(); // リクエスト数を取得する
}

MBean を実装したクラスを作ろう

では RequestMonitorMBean を実装したクラスを作りましょう。サーバーのリクエストは並列に来るものなので、内部カウンタは AtomicLong を利用します。

public class RequestMonitor implements RequestMonitorMBean {

    // リクエスト数を保持するカウンタ
    private final AtomicLong requestCount = new AtomicLong();

    @Override
    public long getRequestCount() {
        return requestCount.get();
    }

    // リクエスト数をインクリメントする
    public void incrementRequestCount() {
        requestCount.incrementAndGet();
    }
}

MBeanServer に登録しよう

RequestMonitor クラスを作成したら、そのインスタンスを MBeanServer という MBean を管理するためのクラスに登録する必要があります。オブジェクト登録時にオブジェクト名を任意に決められるので、わかりやすい名前を付与しましょう。オブジェクト名には様々な属性値を付与することができますが今回は省略します。下記コードはモニタリングを行う前の部分(通常はアプリケーション起動時)で処理されるようにします。

RequestMonitor monitor = new RequestMonitor(); // MBean オブジェクトの生成
String name = "com.cybozu.server:type=RequestMonitor"; // MBean 名
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer(); // MBeanServer を取得
mBeanServer.registerMBean(monitor, new ObjectName(name)); // 登録

メトリクスを収集しよう

ここまで準備が整ったら、あとは RequestMonitor クラスのインスタンスに、適切な箇所でリクエスト数をインクリメントしていくだけです。イメージ的には下記のようなリクエストを受け付ける部分にコードを差しこめば OK です。

一つ注意点があります。ここで使う monitorMBeanServer に登録したオブジェクトと同じオブジェクトを使うようにしましょう。このオブジェクトの受け渡しが手間になることもしばしばあるので、RequestMonitor のようなクラスはシングルトンにするという手もあります。

public void doGet(Request req, Response res) {
    monitor.incrementRequestCount(); // リクエストが来たらカウンタをインクリメント
    ...
}

モニタリングしよう

いよいよモニタリング出来る状態になりました。ここで、正しく外部からメトリクスを取得出来るか試してみます。JMX に対応していればツールは何でも良いのですが、手元で気軽に試すには jconsole が簡単です。jconsole は JDK に同梱されているのでターミナルで jconsole と打てば起動するはずです。

jconsole 起動

自身で起動したアプリケーションを選択して [Connect] を選択、その後 [MBeans] タブを開くと左ペインに MBean オブジェクトがあるはずなので、そのオブジェクトのツリーを展開すると今回のメトリクスが表示されていることが確認できるかと思います。今回は実験でサーバーに 5 回アクセスしたので、[Attribute value] に RequestCount が 5 と表示されています。

メトリクス表示

実際に運用環境でモニタリングする際は RMI を用いてリモートから値を取得できるようにしましょう。RMI (Remote Method Invocation) とはその名の通りリモート環境の Java のメソッド呼び出しを行える仕組みです。起動オプションでプロパティを指定すれば RMI が有効になり、リモートで JMX メトリクスを収集できるようになります。簡単に動かすための例を示します。

  • -Dcom.sun.management.jmxremote
  • -Dcom.sun.management.jmxremote.port=18686
  • -Dcom.sun.management.jmxremote.rmi.port=18686
  • -Dcom.sun.management.jmxremote.authenticate=false
  • -Dcom.sun.management.jmxremote.ssl=false

ポート番号は適当な空いているポートを使いましょう。RMI は外部から接続できるとは言えインターネット経由で誰でも接続できる状態にしてしまうとセキュリティホールになるので注意してください。RMI を呼び出す際に認証することもできるので、環境に応じてセキュリティ設定をしましょう。仕様はこの辺りにあります。

ポートを開けたり、MBean 周りのメソッドの実行などは Java Security Manager の権限を必要とします。必要に応じて権限も修正しましょう。

以上で、無事 JMX を用いてモニタリングを行えるようになりました。

サイボウズの JMX 活用例

サイボウズでの JMX の活用例を紹介します。

まずひとつ目は定番である JVM メモリ量です。単にプロセスの使用メモリ量を表示するのではなく、コードキャッシュ容量や OLD 領域、EDEN 領域などに区分けして可視化しています。メモリ状況はモニタリング用の特別なコードを書かずとも取得できるので、このようなグラフを作るのは非常に簡単です。

Datadog-Memory

こちらはとある Java プログラムの内部キャッシュ状況です。キャッシュのサイズや、キャッシュにエントリを挿入した回数、ルックアップ回数、ヒット率などを表示しています。

Datadog-Cache

最後に、ある非同期ジョブ実行サービスの各種ジョブの実行状況のグラフです。ジョブ実行キューが滞留してしまった際などはこのようなグラフを見ると異常な形をしていることが多く、ひと目で状況が理解できます。

Datadog-JobCount

プロセスの使用メモリ量などは JMX を使わずとも取得できますが、内部キャッシュのルックアップ回数のような細やかな値も取得できるのは JMX の面目躍如といったところだと思います。

終わりに

モニタリングはシステムの中でも無限に追求できてしまう部分です。アラートのしきい値をどれくらいにすれば良いのか、どのメトリクスを収集すれば良いのか、どうやって収集するか、モニタリングシステムのスケーラビリティ問題、等々追求しようとする限り終わりがありません。

個人的には、モニタリング環境がどれだけ整っているか、という指標はわりとシステムの成熟度を表しているのではないかと思います。アプリケーションがダウンした際に即座に対応できたり、負荷状況を確認できたりすることはアプリケーションをより良い方向に進化させるきっかけとなるからです。アプリケーション開発とモニタリング、この両輪が揃うことでシステムが成熟する方向に進むことができ、結果、開発者やユーザーの幸福度を増大してくれるものだと信じています。きっと、 JMX はその一端を担ってくれることでしょう。

それでは、良いモニタリングライフを!

参考

 

福岡・広島に開発拠点を設立します

こんにちは、西日本開発部長の岡田(@y_okady)です。2018年1月1日付で大阪開発部と松山開発部を統合し、西日本開発部を設立しました。そして、福岡と広島の開発拠点設立を進めていくことになりました。

f:id:cybozuinsideout:20180124181057j:plain

私が2014年に大阪にUターンしてから3年半が経ち、住みたい場所で働けることによるQoLの向上を日々実感しています。大阪最高やでホンマ。

サイボウズでは「100人100通りの働き方」を理想に掲げており、みんな住みたい場所で働けばええやんという考え方が根付いています。一方で、住みたい場所にオフィスがないと「仕事を諦めて移住する」か「移住を諦めて仕事を続ける」かの選択を迫られるのが現実です。私は幸運にも大阪開発拠点設立のタイミングで移住が叶いましたが、より多くの人が住みたい場所で働けるように、西日本開発部の設立、そして福岡と広島に開発拠点を設立することを決めました。

働く場所の自由化

サイボウズでは「働く場所の自由化」を実現するために、チームメンバーが異なる拠点や在宅など離れた場所で開発するリモート開発を推し進めてきました。「働く場所の自由化」は企業にとっては災害対策や人材確保の面で避けられない問題ですが、一方でエンジニア個人にとってもQoL向上や生産性向上などプラスの効果が見込めます。現代の日本において、非常に重要な取り組みになるのではないかと思っています。

www.slideshare.net

なぜ福岡と広島?

福岡・広島ともに人口が多く、サイボウズにも多くの出身者が在籍しています。将来、社内のエンジニアがUターンを希望する可能性の高い地域だと考えています。実際、昨年まで松山開発部長を務めて現在西日本開発部副部長の水戸将弥が、2019年1月に地元広島へ移住することが決まっています。福岡についても、数年後の移住をぼんやり考えていると公言しているエンジニアがいます。

従業員が増えれば増えるほどそういった要望も増え、多様化していきます。また、社内に限らず、家庭環境の変化などで移住を考えている人は世の中にたくさんいると思います。福岡と広島に拠点を作ってもみんなの希望を叶えられるわけではありませんが、少しずつやれるところからやっていこうと考え、まずは福岡と広島から始めることにしました。

福岡と広島以外は?

そうは言っても、全国に拠点を作るまでみんなの希望を叶えられないようでは「働く場所の自由化」なんて夢物語でしょう。拠点を作るにはそれなりのコストもかかりますし、全国に拠点を作るのは非現実的です。

サイボウズには、無理すれば出社できなくはないけど天候や家庭の事情でリモートワークをする人がたくさんいます。オフィスにいても家にいても、たとえチームメンバーが全員バラバラの場所で働いていても、効率よく開発できる環境がここ数年でだいぶ整ってきました。そろそろ、オフィスへの出社が難しい場所でリモート中心で働くエンジニアが増えても良い頃かなと感じています。それが当たり前になれば、より多くの人の希望を叶えられそうです。

現在のところ、週2出社・週3在宅1ヶ月間限定の週5在宅が最大のリモートワーク活用事例で、これぐらいなら何の問題もないことが実感できました。これ以上になっても業務に支障はないと思いますが、たまにはチームメンバーと直接顔を合わせたいと思える職場環境にしたいですね。

We are Hiring!

西日本開発部設立に当たって、福岡・広島・リモートで働きたい開発エンジニアの募集を開始しました。「チームワークあふれる社会を創る」という理念に共感してくれる仲間を募集中です。住みたい場所に住んで、いろんな場所で働く仲間と力を合わせて、世界中のチームを支えるサービスを一緒に開発しませんか?ご興味ある方はWantedlyで「話を聞きに行きたい」ボタンを押していただけると嬉しいです。

また、今年は東京や大阪でのUターンMeetup開催や、福岡や広島でのMeetup開催・イベント出展を計画しています。サイボウズで働くことに興味を持ってくださったみなさんとお会いできる日を楽しみにしています!

www.wantedly.com

www.wantedly.com

www.wantedly.com

 

運用本部長を退任して Neco プロジェクトに専念します

前運用本部長の ymmt です。 1 月 1 日付けで運用本部長を退任して、cybozu.com のアーキテクチャ刷新プロジェクト Necoに専念することにしました。

blog.cybozu.io

この記事では運用本部を設立して 4 年間でやってきたことをまとめつつ、Neco プロジェクトについてお伝えします。思いを込めたら少し長めの記事になってしまいましたが、Neco で取り組んでいる Kubernetes を中心にした取り組みを末尾で紹介しています。

運用本部とは

自社の情報システムと顧客向けクラウドサービス cybozu.com の運用をミッションとする本部です。 4 年前に私が初代本部長となって設立したのですが、それ以前は開発本部所属のエンジニアが運用業務をしていました。

開発本部のミッションには運用業務が明示されていなかったこともあり、例えば情報システム部は存在していませんでした。 そのため数名のインフラ系エンジニアで 500 名近い社員の PC を、サービス運用の傍ら面倒を見ていました。

この体制のままでは人員やサービス運用の規模拡大に対応できないと考え、システムの運用と継続的な改善をミッションとして運用本部を設立したのです。

4 年間の歩み

運用本部は社内の情報システムを管轄する情報システム部と、自社クラウドサービスを管轄するサービス運用部で構成されます。 発足当初の所属社員数は 14 名でしたが、この 4 年で 37 名まで陣容を拡大しました。全体の社員数は 458名から 730 名に増加しています。

本部長として力を入れてきたことは様々ありますが、時間を要したという点では以下が挙げられます。

  • セキュリティ対策
  • 情報システム全体の見直し
  • サービス運用体制の強化

それぞれ少し詳しく解説していきますが、実現したのは本部内外の社員の方々ですのでそこはお間違いなく。

セキュリティ対策

cybozu.com は企業向けクラウドサービスですので、顧客データの保護は最優先課題です。サービス自体はもちろん、 それを扱う社内の情報システムのセキュリティも万全でなくてはなりません。

一方で、完璧なセキュリティというのもまたありえません。未知の脆弱性を突くゼロデイ攻撃がきたり、 ソーシャル・エンジニアリングで従業員が騙されてしまったり、最悪の場合内部犯行という可能性だってあります。

備えよ常にとセキュリティの原則と方針を示して、年々着実に対策を積み上げてきました。 結果として大きな事故なく運用してこれたことは素直に嬉しい点です。 下記資料は 2 年前のものですが、当社のセキュリティ対策の一部を解説したものです。

情報システム全体の見直し

情報システム部がなかったので、当初 2 年間は部長を兼務して部内の体制の整備と、社内システムの刷新を指揮してきました。

変わらなかったものはほとんどないというくらい、ネットワーク構成も PC やスマホの端末管理も電話等のコミュニケーションシステムも軒並み刷新したのですが、その背景にはサイボウズが目指す「100人いたら100通りの働き方」ができる会社を実現する必要があったことが挙げられます。

cybozu.co.jp

例として、当社は規模の割に拠点数が多いです。日本国内の主なオフィスで 4 箇所、海外にも 3 拠点ほどあります。それぞれの拠点の増床や引っ越しも頻繁で、常にどこかしら工事をしています。業務都合もありますが、働きたい場所で働けるというのを重視した側面もあります。なんにせよ、そのような頻繁な引っ越しや拠点の追加に情報システムが耐えられるよう、主要システムはデータセンターに集約し、各拠点は IT システムとしては端末化させました。

また、いつでも在宅勤務できる制度を支えるために、Cisco のビデオ会議システムを導入して、在宅・拠点間でいつでも会議ができるシステムを整備しました。 在宅勤務を支援するため、自宅作業用の PC やスマホを希望する全社員に支給する制度を導入したりもしています。

www.cisco.com

エンジニアの働く環境も、元(?)エンジニアの視点で必要十分になるよう整備しました。

cybozushiki.cybozu.co.jp

サービス運用体制の強化

cybozu.com を運用する人員の拡充に努めると同時に、当番制度の導入や待機手当などでサービス運用を支える社員に過剰な負担がかからないよう仕組みを整えました。 また、SRE チームとしてソフトウェアエンジニアが継続的にシステムの運用を改善できるよう取り組んでいるところです。詳しいことは以下の資料をご覧いただくとして、例えば緊急警告に対応する当番は、終日在宅勤務で OK で、いつ寝ていても良いです。

また Linux やオープンソース開発に関して著名な開発者である小崎資広氏、武内覚氏を技術顧問に招請しました。

blog.cybozu.io

さらに、サービスの成長に耐えられなくなることが予想されたシステムのアーキテクチャを見直して刷新するべく Neco プロジェクトを立ち上げた・・・のですが、こちらは残念ながらログ基盤の刷新を除き進捗が芳しくありません。理由ははっきりしていて、専従できる社員をあまり割り当てられなかったためです。

www.slideshare.net

これからの Neco プロジェクト

前置きが長くなってすみません。ここからが本題となります。

ここまで cybozu.com のアーキテクチャ見直しプロジェクト Neco は開発本部・運用本部合同のプロジェクトとして進めてきました。 しかし昨年、海外向けブランドである kintone.com を海外の IaaS に移し、海外現地のデータセンターで運用することを決め、発表しました。

topics.cybozu.co.jp

これに伴い Neco プロジェクトの一方の責任者である開発本部長 佐藤鉄平が、kintone.com の IaaS 化プロジェクトの責任者となりました。 IaaS 化プロジェクトは別の記事で今後紹介を予定しています。

専従者が少なく、責任者も抜けるということで Neco プロジェクト体制の見直しが必須となったわけです。一方良い状況として、昨年来エンジニア採用をエンジニア自身が力を入れて取り組むようにしてきた結果、ここのところ採用が絶好調です。お陰で Neco プロジェクトを専従体制で進める目途が立ちました。

そこで、私も思い切って運用本部長を退任し、Neco プロジェクト責任者として専従する体制とすることにしました。 後任の本部長を任せられる逸材に恵まれてのことではあります。

そういったわけで今年 1 月の頭からプロジェクトのゴールやスコープも整理しなおし、心機一転取り組んでいます。 全面 IaaS 化は先に紹介した kintone.com のプロジェクトが担うことになりましたので、Neco ではそこまでは踏み込まず、 自社データセンター環境の改善に集中します。

まずはハードウェアプロビジョニングの容易化とアプリケーションのコンテナ化をテーマに、以下の調査を進めています。

いずれも調査段階で採用を決めたというわけではないのですが、Kubernetes と Calico は採用するつもりで調査しています。 これらの成果をベースに、来年再来年で各種ミドルウェアのスケーラビリティや運用性を向上させ、現 cybozu.com からシステムを移動させていくつもりです。

最後に

というわけで、進捗が芳しくなかった Neco プロジェクトですが、本部長を退任してがっつり取り組んでいくことにしました。 cybozu.com は今や売り上げの 7 割近くを占める主要サービスで、今後も長く成長し続けることを見込んでいます。 Neco プロジェクトを完遂して、今後の成長を支えられるよう不退転の覚悟で取り組んでいきます。

この取り組みについて興味があるとか、協力したいという方はぜひご連絡ください。まだまだ人員募集中です! 以下は SRE 枠の募集ですが、Neco に興味ある旨お伝えいただければ問題ありません。

www.wantedly.com

毎月ミートアップイベントも開催していますので、そちらもお気軽にどうぞ。