<左から大林組　山口 昌良氏、畑田 光氏、広田 勝氏、KDDI柳澤、冨岡>

データセンター企画リーダーの柳澤です。今回の記事もTELEHOUSE OSAKA2です。9月15日掲載の設備公開の記事に続いて、この巨大なデータセンターの建設をお願いした大林組へのインタビューをお届けします。KDDIが要求する堅牢なファシリティ、グローバルスタンダードなデザインなどに、どのように工夫して応えていただいたのかについて取材した内容をご紹介していきたいと思います。取材にご協力頂いたのはTELEHOUSE OSAKA2の建設の統括責任者である大林組 畑田 光さん、建築責任者の広田 勝さん、設備責任者の山口 昌良さんです。KDDI側のTELEHOUSE OSAKA２企画担当である冨岡とともにお話をお聞きしました。

各国のお客様に配慮されたデザイン、大阪らしさ、KDDIらしさを追求

<TELEHOUSE OSAKA2 1階エントランス>

＜大阪城、石垣、日本刀、屏風をモチーフに大阪らしさを表現＞

柳澤：TELEHOUSE OSAKA2を今日初めて見学して感じたのは、建物のデザイン性の高さです。無機質になりがちなデータセンターに様々な工夫がなされ、居心地のよい空間になっているのを感じました。デザインに関して一番のアピールポイントはどの部分になりますか？

大林組：やはり１階のエントランスですね。大阪のデータセンターらしさを表現するために、大阪城の屏風、石垣、日本刀をイメージしてデザインしています。データセンターは機密性の高いデータを扱う場所であり、目立ったデザインはできないですが、サイン計画などちょっとした色使いで無機質な空間に命を吹き込むことを意識してデザインしています。サーバー室は、KDDIコーポレートカラーのブルーとauのオレンジを用いてKDDIらしさを出すことに主眼をおいています。

<auカラー、KDDIカラーを基調にデザインされたサーバルーム>

また、階段室の手すりの色にも東側は生駒山をイメージした緑を、西側は大阪湾をイメージした青を取り入れています。細かな点ですが機会があれば見ていただきたいですね。

柳澤：細部にわたって配慮いただき感謝しています。各所にポイントとしてデザインされている絵やロゴも外資系のお客様にも好評です。データセンターには、各国のお客様が来訪されますので、一目で何の目的の部屋なのかわかることは意外に重要なことですよね。外観のモールス信号によるデザインのユニークさも気に入っています。

限られたスペース、スケジュールの中で活きる経験と技術力

柳澤：今回の建設に際して、デザイン以外にも色々と工夫して頂いた点があったかと思います。一番ご苦労されたのは、どのような点でしょうか？

大林組：まずは、短工期での大規模ビルの建設案件だったため、限られた工期の中でいかに効率的に工事を遂行するかに最も苦心しました。2014年4月に着工し、2015年7月にビルを完成させるために最も時間の掛かる躯体工事期間中（約6か月）は24時間を4つの作業時間帯に分け、昼夜関係なく作業を行いました。巷でも工事のスピードの速さが評判で「こんな猛スピードの鉄骨建方を見たのは初めて」などとSNSに投稿されたこともありましたね。鉄骨の組み立てと、外装のPC板の作業は同時には出来ないので、夜に鉄骨、昼にPC板（プレキャストコンクリート：外装材の一種）と倍速で作業を進めていき、タワークレーンも通常は1台のところを2台用意して高所作業のスピード化も図りました。一日あたり150トンもの鉄骨を上げ、鉄骨製作会社もフル回転でしたね。

柳澤：短工期で取り組んで頂くには、様々な工夫が必要だったかと思いますが、具体的にはどのような事なのでしょうか？工期のチェックは、どのくらいの頻度で行うのですか？

大林組：工期のチェックは、日々必ず行います。日割りの工程は午前、午後でチェックしています。そこが我々の業務でもっとも肝心なところであり、作業が遅れたり、予定外の事象が起こった時に何を優先して今どの作業を行うかの判断が日々迫られます。こちらの紙面がそれぞれの工程管理表の一部ですが、全体工程、月割り、週割り、日割りの各工程でチェックしていきます。工程表を見れば、「○○の作業はいつ行うのか？」という問いに「2014年、○月○日です。」と即座に答えられるようになっています。これをもって各業者にタイミングと工程内容について説明を行います。以前は、紙面全てを現場に持ち込んでいたのですが、今はiPadで全てのデータが見られるようになっています。

その他の工夫としては朝礼の実施方法があります。高層ビルにおける作業のため、朝礼を１箇所で行うとなると終了後にエレベーターが混み、それぞれの作業場に辿り着くまでに時間がかかってしまいます。１階と１０階のフロアに分け、片方はテレビ会議にするなどして少しの時間も無駄にしない工夫をしていました。

<工程管理表、一人一台支給されるiPadにて現場でのチェックを行う>

柳澤：工期スケジュールの精密さはプロの仕事ですね。依存作業については分岐して記載され、作業の流れがまとまりで見てわかるようになっているのですね。高層ビルのデータセンターは大規模な機械の搬入が多く、エレベータが混み合い、調整が大変だったのではないでしょうか？また、セキュリティ面の考慮も必要なため、普通のオフィスビルとは違ったご苦労があるのでしょうね。

大林組：揚重（ようじゅう：荷揚げのこと）については、専門の業者を採用して、業者のWEBシステムで予定を細かく管理し、昼夜問わず搬入し続けました。上層階への搬入をクレーンで行うなど高層ビルならではの負荷が大きい部分はありましたね。セキュリティに関しては、追求しすぎると利便性が低くなる傾向にもありますが、例えばKDDI社員用とお客様用のエレベーターを分け、それぞれの立場で利用しやすい環境を提供できるよう工夫しました。

柳澤：お客様用のエレベーターは、ご利用階しかエレベーターが止まらないなどセキュリティを意識しつつも、お客様のご利用しやすさを配慮していただいていますね。また都市部の高層ビルというスペースの限られた中でKDDI側の要求である、「離隔を保った電源/通信ルートの冗長性」、「お客様の導入設備に配慮した天井高のクリアランス」、「部屋の面積」などを満たして頂くのは大変だったのではないでしょうか。

大林組：そうですね。間取りは苦労しましたね。メインのサーバルームだけではなく、仮眠室、会議室、シャワールームなどお客様のリラックスやコミュニケーションを確保し、ラグジュアリーな空間を提供できるか？基本的な条件をクリアするための間取りに苦心しました。設計者の手腕ですね。

柳澤：またデータセンターの安全性を確保する上で非常に重要な安全性についても、KDDIの要求であるJDCC Tier4, 想定される最大級の地震に対してもサーバ室を200gal以下に抑える免震構造を見事に満たして頂きました。

大林組：4種類の免震装置を組み合わせて実現しています。1.鉛プラグ挿入型積層ゴム、2.直動転がり支承、3.オイルダンパー、4.弾性すべり支承 を設置し、大きな地震が来ても、機器を守るための揺れにとどめる工夫を行っています。ちなみに、弾性すべり支承のすべり板は一辺が3.2ｍで日本最大級ですが、大きさの関係で昼間は道路運搬ができず、警察の許可を受けた上で、夜間に運び込みました。

110万時間、無事故・無災害達成。徹底した安全管理を実施

柳澤：徹夜も含む建築作業時間は110万時間に及んだそうですね。事故があれば作業がストップしてしまいます。この長時間に亘る作業を無事故でスケジュールの遅延も無く進めて頂けたことに感謝しています。社内で安全管理への取組みはどのようなことをされているのでしょうか？

大林組：作業のインパクトを危険度や発生頻度により点数化し、日々の作業に伴う現場の特殊性やリスクを作業に入る前に必ず確認します。その他、高齢者は高所作業をしないようステッカーを付けたりと、周りから安全配慮できる環境を作っていますね。また、ビルの周りはレーザーバリアが張り巡らされ、タワークレーンの吊り荷が敷地境界を出ると警報がなる仕組みになっており、クレーン同士も衝突防止装置を入れているので、相当な不注意がなければ、事故は起きない環境になっています。

柳澤：あと、作業員の安全確保の取組みとしてSMAC(Safety/ Manner up /Ajust /Clean up)活動という取組みも興味深いですね。作業員一人一人のマナーアップやコミュニケーションの円滑化、一般道の清掃など、目の前の危険予知だけではなく、周囲の理解を得ながら作業員一人一人が安全に働きやすい環境が得られるよう様々な配慮をされているのがよくわかりました。本日はお時間頂きありがとうございました。

対談を終えて：

データセンターのビルは大きな構造物ですが、空間的にも時間的にも緻密な設計がされていることを改めて認識させられました。当社の要求する仕様や工期は相当に厳しかったと思われますが、その裏ではこのようなご苦労と工夫があったのかと感心しています。見事に無事故・無災害で工期遅延なく、洗練されたデザインに仕上げていただいたことに感謝いたします。

皆様のお越しの際には是非このプロの作品であるTELEHOUSE OSAKA2をご堪能いただければ幸いです。

左からKii 石塚 進氏、KDDI 平川 恭宏　Kii 本社ビルにて

KDDIクラウドプラットフォームサービス mBaaS by Kii （以下、KCPS mBaaS by Kii）の開発担当の平川です。KCPS mBaaS by Kii は、Android、iOSといったモバイルアプリを始めとし、IoT（モノのインターネット）にも対応しており、アプリケーション開発に欠かせないユーザー管理、モノ管理、データ管理、プッシュ通知、位置情報、アプリ分析といったサーバーサイドの機能をご利用いただけるクラウドサービスです。国内初、イントラネット接続回線 (KDDI WVS)とインターネット接続回線をバンドルし、業界トップクラスの高稼働率を実現するクラウド基盤KCPS上でSLA（サービス稼働率保証）を提供するキャリアならではのエンタープライズmBaaSとなります。KDDIは、モバイルアプリやIoTデバイスを活用した業務効率化など法人のお客さまの経営課題を先進的なワークスタイルの実現とあわせて強力にサポートしていきます。

1．mBaaSとは？

「mBaaS」ってなに？と思われるかたも多いと思いますので、「mBaaS」について以下に解説します。mBaaSは、PaaS (Platform as a Service)のカテゴリに位置づけられるサービスです。

mBaaSを利用すると、今までのようにクライアントサイド、サーバサイドの両方を構築する必要はありません。サーバサイドの機能は、クラウドで提供されます。お客様はクライアントサイドのアプリケーションを開発するだけになります。具体的には、本サービスで提供するSDKを利用しアプリケーションを開発することでサーバサイドの機能が利用できます。例えば、KCPS mBaaS by Kii のシステム上に、ユーザー情報を登録して、認証したいといった場合、どのようにコーディングすればよいかは、http://documentation.kii.com/ja/ に準備されています。準備しているドキュメント類、サンプルコード集は、豊富に提供されていますので、開発もスムーズに進められます。

例えば、以下コードで、KDDIが提供するサーバ（KCPS mBaaS by Kii のシステム上に）へユーザ登録することができます。1行目の「user_123456」がユーザ名、2行目の「user_123456@example.com」がEメールアドレス、3行目の「+819012345678」が電話番号、7行目の「123ABC」がパスワードになります。

KiiUser.Builder builder = KiiUser.builderWithName("user_123456");
builder.withEmail("user_123456@example.com");
builder.withPhone("+819012345678");
KiiUser user = builder.build();

try {
  user.register("123ABC");
} catch (AppException e) {
  // Sign-up failed for some reasons
  // Please check AppException to see what went wrong...
} catch (IOException e) {
  // Sign-up failed for some reasons
  // Please check IOExecption to see what went wrong...
}

お客様は、サーバ購入、サーバの設計・設定等をすることなく、アプリケーションでコーディングするだけで、サーバの機能を手に入れられます。

 2.mBaaSの価値

mBaaSを利用することで、どのようなメリットを享受できるかイメージがつかみにくいと思います。本サービスを利用することで、サーバサイドの開発にかかるコスト（サーバ購入/設計/保守等）・期間を削減することができます。これにより、お客様は重要な施策の検討等、本来注力すべき課題にコスト・稼働をかけることができます。これにより、お客様のビジネスの発展に貢献します。

ご経験のある方は、ご存じの通り、自社でサーバを保有すると簡単に挙げただけでも、以下対応が必要です。これらの作業が不要になることは、非常に大きなメリットです。

1)サーバ設置場所の検討
2)立架、ネットワーク・電源ケーブル敷設、サーバ搬入等の工事
3)購入するネットワーク・サーバ機器の検討・導入・保守運用
4)システム構成するネットワーク・サーバ・サーバアプリケーションの設計・実装・試験
5)ネットワーク・サーバ・サーバアプリケーションに対するセキュリティ対策の設計・実装・試験
6)ネットワーク・サーバ・サーバアプリケーションの監視・運用業務（脆弱性に対するパッチ適用等）

3.KDDIが提供する「KCPS mBaaS by Kii」の価値

mBaaSサービスは、他事業者でも展開されていますが、KDDIが提供するKCPS mBaaS by Kiiの特徴は次の通りです。

3-1. イントラネットで利用できるmBaaS

イントラネットでのmBaaSサービス利用が可能になります。現在、他mBaaS事業者ではインターネットを前提としたサービスしか提供されていません。KCPS mBaaS by Kiiでは、セキュリティに関心の高いエンタープライズ向けのお客様を意識したイントラネットでのサービス利用環境を提供します。これにより、お客様宅内のサーバともシームレスに連携することができます。どのようにセキュリティを担保しているかといいますと、KCPS mBaaS by Kiiのシステムとお客様宅内システム間を、暗号化して通信することで実現しています。

マルチテナント構成で、セキュアの通信を実現するために、KDDIがお客様毎に払い出す証明書にて認証しています。通信の都度、この証明書と認証キーの両方にて認証を行い、認可された場合のみ、お客様のネットワークへの通信経路を確保することで、通信を許容しています。この方式により、他社のネットワークへトラフィックが流れることを防いでいます。

3-2. 安心・安定のKDDIクラウドプラットフォームサービス基盤

KCPS mBaaS by Kiiは、安定稼働のKCPSと、99.999999999999%の堅牢性をもつ、KDDIオブジェクトストレージを利用して構築しています。またKDDI Business IDとの連携も可能なため、セキュアな環境でシームレスにKDDIの他サービスを利用することが可能です。

3-3.アプリケーション開発のサポート

KCPS mBaaS by Kiiを利用したアプリケーション開発にご不安をいただくお客様もおられると思います。そのようなお客様のために、KDDIがアプリケーション開発までサポートすることで、高品質・低価格・短期間でのアプリケーションの開発を実現します。

3-4. IoT（Things）機能の提供

KCPS mBaaS by Kiiは、IoT (Internet of Things) における Thing（モノ）を取り扱う仕組みも提供しています。一般的に、IoTプラットフォームと称しているものは、M2Mプラットフォームであり、ユーザという概念がないものがほとんどです。KCPS mBaaS by Kiiは、ユーザとモノを関連づけて管理することが可能です。モノ（Things）で発生したデータは、Thing用のBucketに登録されます。このBucketは、ユーザ用のBucket等と独立しているため、個別の管理が可能です。

本構成により、柔軟にアクセスのルールを設定することができます。以下のように、Thingからユーザ/グループへのデータのアクセスを規制することもできますし、ユーザ/グループへのアクセスを許可させることもできますので、お客様の用途に応じた柔軟な利用が可能です。

４．最後に

KCPS mBaaS by Kiiは、2週間に1回のペースで新機能の導入、機能改善を行っています。お客様の声をいち早くお聞きし、必要な機能追加を随時実施していきますので、ご期待ください。最後まで、お読みいただき、有難うございました。

データセンター企画リーダーの柳澤です。3週にわたってTELEHOUSE OSAKA 2の記事を掲載していますが、今回は最終回になります。TELEHOUSE OSAKA 2の運用を担当するメンバー3名に集まってもらい、これからどのような運用を目指していきたいかを議論した内容をお届けします。写真は左からTELEHOUSE OSAKA DC運用チームの運用者　國岡さん、北岡さん、リーダーの本多さん、柳澤、データセンター企画担当 冨岡です。

TELEHOUSE OSAKA 2の運用、ついに始動。

柳澤：TELEHOUSE OSAKA 2の建設が無事に終わり、間もなく実際にお客様設備が搬入され、本格的な運用作業が始まりますね。まずはこれからの意気込みとして、どのような運用を目指して行きたいですか？

運用者：TELEHOUSE OSAKAの強みの一つは、お客様設備を丁寧にサポートするためにKDDIスタッフが十分な知識と経験を持っていることだと思います。TELEHOUSE OSAKAの第1ビルの方は約25年前より運営していますが、我々も頻繁にお越し頂くお客様のお名前は把握していますし、KDDIだからと親身にお付き合い頂くお客様が多いというのも大阪ならではの特徴です。中には、当社スタッフに対してカレンダーやお土産を持ってきていただけるお客様もいらっしゃいます。

柳澤：大阪の風土に根ざした運用を心がけているということでしょうか。

運用者：お客様とTELEHOUSEの運用員の間は、システマティックな対応ではなく、人間同志の温かいお付き合いが重要だと思っています。私は東京でのデータセンター運用経験もありますが、大阪のお客様はそのあたりを重視されているのかなと感じています。キッチリやることはもちろん大切ですが、曖昧なところが好まれたりします。期待されることも大きいわけですが、お客様の要望に応えられる運用員でありたいと思っていますね。

柳澤：TELEHOUSE OSAKA 2は同じビル内に営業やSEも勤務し、お客様の要望を直接相談していただけるのも、安心していただけるポイントですよね。お客様の要望に応えるための環境が整っていると思います。

運用者：はい、そこもTELEHOUSE OSAKA 2のもう一つの強みです。メニューにないことへの組織の対応力、営業、SEとの連携など、KDDIの総合力にご期待いただきたいですね。

お客様の規模も国籍も多様化した中で、どうご満足頂くか？

TELEHOUSE OSAKA 2をご利用頂くお客様のお申込が続々と増えてきている状況にありますが、ご利用いただくお客様の企業規模など特徴はありますか？

運用者：ご利用予定のお客様は実に多様性に富んでおり、企業規模も中小企業から超大手企業のお客様など、規模も国籍も様々です。また、お客様の要望は様々であり、例えばセキュリティ管理などに関しても厳重な管理を望まれる方もいらっしゃれば、またそれらを面倒に感じる方もいらっしゃったりと両極端な一面もあります。基本的なルールにのっとった中での運用を遂行するのはもちろんですが、お客様に気持ちよくご利用頂くための配慮を忘れないよう心がけて業務を行っています。

柳澤：企業規模がそれだけ幅広い状況ですと、運用も幅広く対応せざるを得ないですね。多様化するお客様要望に応えるために工夫されていることなどありますか？

運用者：お客様の声に直接耳を傾ける努力はしていますね。日々の運用の中でお客様から実際に声をお聞きし、ご要望点を掘り下げて把握することは重要かと思っています。TELEHOUSE OSAKAの第1ビルにおいても30年前に建設したビルのため、建設当時との状況が異なり不便な面が生じてくるわけですが、これまでお客様から頂いたご要望を忘れる事無く関連部門への交渉を重ねて改善活動は常に行っています。

例えば、第1ビルでは、8階にあった受付を１階へ移し、お客様のラックまでの距離を最短化するなどの対応を行いました。お客様の手間をかけずに心地よくご利用頂けるように、運用だけではなく幅広いサポートを提供したいですね。

TELEHOUSE OSAKA 2はKDDIデータセンター運用の集大成。いいとこ取りの運用を目指す

柳澤：TELEHOUSE OSAKA 2運用の立ち上げに当たり、今まで日本全国でTELEHOUSE の運用を担当していた、いわば運用のプロを中心に据えてお客様をお迎えする準備を整えているのですね。

運用者：はい、運用員として新たに6名が加わり、24時間体制で常駐します。これまで長年に渡りKDDIの全国のデータセンターにて経験を積んだ運用者を大阪に呼び寄せ、彼らを中心にチームを組むことになります。

柳澤：世界13カ国/地域・24都市・46拠点以上あるTELEHOUSEのこれまでの運用のノウハウを実際に活かせそうですか？

運用者：多摩や大阪第１ビル手順書やお客様対応などの良い事例はどんどん採用し、いいとこ取りした運用の最高峰を目指して準備を進めているところです。これまでは立ち上げのため専任チームで対応してきましたが、これからは第１ビルの経験者や他の業務の経験者をクロスさせて運用に厚みを増していければと考えています。堅牢な施設やセキュリティ機能、ファシリティの充実にも注目が集まっていますが、TELEHOUSE OSAKA 2の運用にもご期待ください。

柳澤：これからTELEHOUSE OSAKA 2の運用を盛り上げていってください。よろしくお願いします。

<対談を終えて>

グローバルの統一ブランドでTELEHOUSEを展開している中で、大阪らしくお客様の心に寄り添った対応していることがとても好感が持てました。データセンターサービスは堅牢性、高電力対応、セキュアな環境、利便性等が求められるものですが、まとめるとお客様に”安心”を提供するサービスだと考えています。安心という意味では、ファシリティによるハード面だけでなく、お客様に寄り添う運用というソフト面は重要な要素だと思います。TELEHOUSE OSAKA 2のご利用の機会があれば、是非そのソフト面の安心も体感していただきたいと思います。

３回のTELEHOUSE OSAKA 2のオープン記念記事はいかがでしたでしょうか。皆様に少しでも興味を持っていただけたなら幸いです。TELEHOUSE OSAKA 2をどうぞよろしくお願いします。

TELEHOUSE OSAKA 2を体感いただける動画もお楽しみください。

KDDIクラウドプラットフォームサービス(以下、KCPS)のサービス運用を担当している佐藤優です。KCPSの2015Q3稼働率(※)は99.9998%でした。

（※）稼働率＝月間VM稼働時間累計／（月間VM稼働時間累計＋月間VM故障時間累計）ただしメンテナンス時間を除く

3ヶ月間の故障部位内訳は、サーバ・ホスト故障 78%、ストレージ故障 11%、仮想ネットワーク故障 11%でした。

KCPSの「よくあるご質問」について

このブログでVM稼働率の公開を2014年Q3に開始して以来、今回で5回目の記事エントリーとなります。KCPSの運用担当では、SLA及び一層のサービス安定稼働の達成の為、引き続き品質改善の取り組みを行っておりますが、あわせて今後様々なナレッジを公開し、より安心してサービスをご利用頂ける様にしたいと考えています。サービス品質の観点からも、KCPSをご利用頂く際にVM稼働率と同様に重要なのは、お客様のシステム検討～構築～運用迄の各フェーズにおいて、想定外のトラブルなくスムーズにご利用頂けることであり、ドキュメントサイトにて各種コンテンツやサービスの整備を進めています。

ドキュメントサイト

当社のKCPS運用窓口には、日々お客様から様々なご質問・ご申告を頂いていますが、事前に当社から迅速に有益な情報を発信することで、問題の発生を未然に防止できるケースがあると考えています。その為、特によくお問い合わせを頂く内容について、わかり易く情報提供させて頂く目的から、「よくあるご質問」を継続的に拡充しています。

「よくあるご質問」ページ

「よくあるご質問」の掲載にあたっては、お問い合わせ内容をサービス仕様／提案／構築／利用の各フェーズに分類／分析し、再現検証も行うことで、お問い合わせ頻度や影響度から優先的に掲載するナレッジを選択しています。

今後は、KCPSを利用した当社の事業用システム構築～運用のノウハウや、数多くの法人様案件でKCPSをご提案し導入させて頂いた当社SEのノウハウも積極的に公開し、共有させて頂く予定ですので、ご期待ください。最後までご覧いただき、ありがとうございました。

　　　　　　　　Kiiコンソーシアム運営3社：左からKii 鈴木 尚志氏、大日本印刷 生田 大介氏、KDDI 日比野 健太郎

「KCPS mBaaS by Kii」企画担当の日比野です。IoT時代の新たな企業間連携を目指す「Kiiコンソーシアム」の設立総会を、10月5日にコミュニケーションプラザ ドットDNPにて開催しましたので、その様子をレポートします。当日は会員企業から総勢60名以上の参加者が集まり、会員向け特別セミナー、今後のWG運営に関するディスカッション、そして懇親会と大いに盛り上がりました。

◆「Kiiコンソーシアム」とは？

まずは「Kiiコンソーシアム」について簡単にご説明させていただきます。「Kiiコンソーシアム」は、BaaS（Backend as a Service）事業を展開するKii、DNP、KDDIの3社が協力して運営するかたちで、2015年9月29日に設立されました。すでに23社の会員企業が参加しており、参加各社がモバイルアプリやIoTデバイスの開発を通じて得られたノウハウや事例、さらにはビジネス面における課題を共有したり、世界の標準化動向や最新のアーキテクチャをより広く把握することで、最適なソリューション創りのスピードアップや品質向上を目指すコンソーシアムです。そこで得られる成果については、今後のセミナーやイベント等を通じて外部へも発信していきます。

◆会員向け特別セミナー＆フリーディスカッション

会員向け特別セミナー最初の登壇は、アシアル株式会社　取締役　マーケティング・事業開発担当　塚田亮一氏より、クラウドベースのアプリ開発プラットフォーム「Monaca」に関するプレゼンが行われました。少し「Monaca」の紹介をさせていただきますと、MonacaはHTML5とJavaScriptを用いた開発手法（HTML5ハイブリッドアプリ開発）で、iOSとAndroidの両OSに対応したアプリを、一度に開発（ワンソースで両OS向けのアプリを開発）できるクロスプラットフォームです。また、バックエンドをKiiのmBaaSと連携することも可能で、これにより、アプリ開発がより簡単に迅速に実現できます。いまでは10万人を超える開発者が利用する「Monaca」ですが、2012年のリリース当時は多くの課題を抱えていたそうです。セミナーでは、如何にしてそうした課題を乗り越えてプラットフォームとして成長してきたかの極秘裏話や、「Monaca」とmBaaSを連携した実践で役立つ活用術、洗練されたモバイルUIフレームワーク（Onsen UI）、具体的な開発事例なども紹介されました。

続いて登壇されたのは、クルマ・ポータルサイト「Goo-net(グーネット)」を運営される、株式会社プロトコーポレーション　ITソリューション2部　エキスパート　富田篤氏です。「モバイル」「IoT」「ロボット」といった、いま誰もがワクワクする様なキーワードでぐっと参加者の興味を引き寄せ、それら異なる様々なデバイスを制御する共通アプリ開発基盤としての「mBaaS」活用など、ユーザー企業ならではの貴重な実践事例が紹介されました。ちなみに、モバイルから簡単に中古車・バイクの情報を検索できる「Gooシリーズアプリ」は、iPhone,Android,iPad,Windowsでリリースされており、470万ダウンロードを達成、月間ユーザー数は60万人以上にもおよぶそうです。

最後は、大日本印刷株式会社　C&I事業部　システムプラットフォーム開発本部　第3開発室　室長　生田大介氏より、今後のワーキンググループ活動に関する案を発表。WGのセグメント分けや具体的な取り組み内容、ゴール設定などについて、参加者の意見を募るフリーディスカッションを実施しました。そこでは、開発視点での意見、ビジネス視点での意見、はたまたアプリ視点であったりデバイス視点であったり、多様な企業が参画する本コンソーシアムならではの、闊達な意見交換が行われました。

◆懇親会

総会前はお互いに少し緊張気味だった参加者同士が、セミナーやディスカッションを通じて徐々に打ち解けあい、懇親会では参加者同士が誰彼ともなく自然にお互いのビジネスパートナーを探したり、今後のWGのあり方などについて深い議論まで交わされていました。また、次回の総会は年明け頃を予定しておりましたが、もっと早く実施したいという積極的な参加者の声が多く、その場で次回は12月開催ということまで決まりました。

◆さいごに

今後、KDDIはこうしたコンソーシアムで得られる知見を、法人のお客様へのモバイルソリューション提案へもどんどん反映させてまいります。「会社でスマデバを導入したけどいまいち業務に活用しきれていない」、「業界や業務に特化したアプリが欲しいが市販のアプリには最適なものがない」という企業のご担当者様は、是非お気軽にKDDIへお声掛け下さい。KDDIは、デバイスだけでなく、アプリケーションからクラウド、そしてネットワークまで組み合わせ、お客様の業務課題やニーズに沿った最適なソリューションをご提案させていただきます。また、モバイルアプリやIoTデバイス関連の事業を行っている企業の皆様で、本コンソーシアムへの入会をご希望の方は、是非、Kiiコンソーシアム事務局までご連絡ください。

Kiiコンソーシアム事務局：kc@kii.com
Kiiコンソーシアムホームページ：http://jp.kii.com/consortium/
※Kiiコンソーシアム事務局およびホームページはKii株式会社が運営しております。

Agile&DevOps推進担当の川上です。今回は開発ツールの話の中でも、アジャイル開発を支えるCIツールについて、もう少し詳細にお話したいと思います。

クラウド時代に手作業？？

KDDI Business IDのシステムは60台以上の仮想サーバで構築されています。これらのサーバに、プログラムのリソースを手作業で配信することを想定してください。

0.sshでログイン
1.資産ファイルを配置
2.アプリケーションサーバを再起動
3.プロセスの稼動状況を確認

当然、商用サービスとして稼動している状況なので、正しいファイルか、正しい配置場所かどうかを確認するといった作業も含みます。1サーバ20分で作業が完了するとしても、60台だとして単純計算で1200分、平行作業で3チーム実施するとしても、400分（6時間以上）必要です。KDDIの社内では、作業はペアで実施しますので、3チーム×2名=6名が必要となります。これでは、商用作業が非常に長時間、高コストなイベントになってしまい、サービスを継続して改善していくという事を実現する上で障害になってしまいます。また、商用作業でサービスを止めるとお客様にご迷惑をおかけし、ましてや手作業によるオペレーションミスなどでサービスを停止させては、信用問題にも発展します。そこで、KDDI Business IDのような常に成長を求められるようなシステム、大量のサーバに同じオペレーションを行うシステムには、自動デプロイの導入をお薦めします。

社会インフラに求められるサービスレベル

KDDIは携帯電話事業をはじめ、様々なサービスを提供しています。特にメジャーな携帯電話事業では、4,000万を超える回線を収容しています。また、それらを支えるサーバや、ネットワーク機器、交換機は全国で数百台、数千台に及びます。通信サービスは、今や電気、水道と同じような社会インフラとして必要なサービスであると考えています。「サーバが止まっていてメールが送信できません。復旧は三日後です」では、ビジネスにもプライベートにも安心してご利用いただけませんよね。社会インフラとなった通信インフラには、当然、高度なサービスレベルを要求され、サービスを支えるシステムの運用にも同じ事が言えます。数百台に及ぶサーバに対してオペレーションを全て手動で行うことは、コストもかかりますし、先ほど述べたサービスレベルを担保することは難しいことです。これまでは、ソフトウェアのアップデート等の作業は、下記の手順を手動で実施していました。

1.旧バージョンのソフトウェアのバックアップ
2.新バージョンソフトウェアをアップロード
3.プロセスを再起動して新しいソフトウェアを起動
4.プロセスの正常動作を確認

勿論コマンドラインで、実施しているので時間もかかりますし、ミスを無くす為のクロスチェックの体制を敷くなど、かなりの労力をかけて実施していました。これらの作業を、お客様への影響を減らす為に夜間に実施していたのです（健康にもあまり良くないですよね）。
※過去に商用作業を手作業で実施していた際、手順書は1作業でA4数十枚になり、百以上のコマンドをコピー＆ペーストするという物でした。KDDI Business IDではこれらの作業をスクリプト化し、CIツールによる自動配布/チェックを実現しています。以前のBlogに記載したBambooにリリーススクリプトを記載し、それらを実行する事で、商用作業のコストとリスクの削減を実現しているのです。

便利であるがゆえに

CIツールを導入/利用する際に、気をつけないといけない事が有ります。当たり前かもしれませんが、「必要な人しか、商用へのデプロイは出来ないようにする」ということです。CIツールの権限管理機能により、そもそも商用環境へのデプロイを行えるアカウントを制限しています。また、デプロイ作業は管理ログを残し、誰が、何時、何の資産をデプロイしたのか追跡できるようにしています。しかし、CIツールは開発に利用しているシステムで、アカウントも開発部門で管理しており、開発部門で、商用環境へデプロイが出来るアカウントを作れてしまいます。そのため、CIツールと商用設備の間のルートに、運用部門が管理しているルーターを設置し、リリース作業の時以外は、運用部門がルートを落としておくという運用を実施しています。これにより、仮に開発部門が間違えて、開発環境ではなく商用環境にデプロイを実施しようとしても、途中のネットワークで止めるというネットワーク上での対策も取っています。

環境マネジメント（違いを把握する）

Bambooでスクリプト化して自動デプロイ、とてもハッピーな事ですが、準備には当然工数がかかります。スクリプトの動作検証をどの環境で実施するか、という点です。当然商用環境と、検証環境では構成そのものの違いや、IPアドレスの違い等、大小さまざまな環境差分が存在します。商用環境と、検証環境でまったく同じ環境を構築するというのはコスト的にも現実的では有りません。

そこで、環境のマネジメントが必要になってきます。検証環境と商用環境の違いを把握し、検証環境で動く物を、商用で動かすには何を行えばよいのか、ということを把握しておかないと、いざ商用作業を行う際に、痛い目を見る訳です。具体的な例としては、OS/ミドルウェア/アプリケーションの設定ファイルをリポジトリで管理し、リリースする環境に応じた設定ファイルを自動的に適用するなどの対応があります。ここでもCIツールが活躍し、環境に適した設定ファイルを読み込むようにします。よく検証環境で使った手順を、商用環境用に変更する際に、変更漏れが発生するという事があります。人の手でやっている場合はゼロにすることは難しいですが、システム化することで、効率的に漏れをなくすことが出来ます。ツールやテクノロジー、テクニックを使って可能な限り手動の作業を減らすことが、コストとリスクを削減することにつながりますが、使う側が人である以上、完璧は有りません。ツールの運用まで含めて、ベストなプラクティスを今後も模索していきたいと思います。

KDDIのアジャイルの取り組みがIT Proに紹介されました。こちらもご覧頂ければ幸いです。
［1］「うちにアジャイルは無理」、既存の社内常識を打ち破る
［2］アジャイルもコーディングも初体験のチームが、内製化を果たすまで
［3］社内技術力が劇的向上、思わぬ不安がマネージャーを襲う

皆様こんにちは、アジャイル開発推進担当の川上です。本日はKDDIのアジャイル開発の現場から、いくつかの失敗談をお伝えしたいと思います。これまでは、うまくいった点や、工夫した点を中心にお話してきましたが、あえて失敗例をお伝えすることで、皆様の気付きになればと思います。

1.プロジェクト立ち上げ時のベロシティ(開発速度)の問題

グラフは、プロジェクトのスタートから1stリリースまでのストーリーの消化曲線です。見てお分かりの通り、初期は全くストーリーを消化できませんでした。当然、PO（プロダクトオーナー）やマネージメント層から、顔を真っ青にして「このままでは終わらないじゃないか」という指摘を受け、最初から頓挫するのではという懸念の声が多数上がりました。実は始める前から、開発環境の構築、CI環境の構築、初対面のプロジェクトメンバーによる不慣れなコミュニケーションの中、最初の1ヶ月ぐらいは、ストーリーは思うように消化出来ないだろう想定はしていました。しかし、その想定をふまえた消化曲線を、関係者へ共有していなかったため、「想定と違う」、「大丈夫か？」という騒動を起こしてしまいました。チームメンバーがどのようにアジャイル開発に慣れていくのか、いつの時点で、どれくらいのストーリーを消化できる見込みなのかという情報を、関係者と合意するという手間を怠った為に、プロジェクトの推進が危ぶまれる状況になってしまいました。進捗が芳しくなく見えることには、ほかにも理由があり、まず「ストーリーの規模が大きすぎる」こと、「機能開発に含まれないタスクを、開始当初は見える化できていなかったこと」です。

ログイン機能を作成する場合に、当然IDとパスワードを入れる必要があります。ログイン時にパスワードを規定回数以上失敗したら、IDをロックするような機能も必要になるでしょう。しかし、それを「ログイン機能を作る」という一つのストーリーで実現しようとすると、ログインに関する非常にたくさんの機能を作りこまないといけないですよね。

そのため、最初は
1.「IDとパスワードを入力して、パスワードがOKだったらログインさせる」というストーリーを作り、次に
2.「パスワードが失敗した数をカウントし、一定回数以上でステータスをロックする」
というストーリーに進むとし、仕様をリリース可能な単位で分割し、機能を実現する方法を取りました。

CI環境の構築、リポジトリの作成、開発ルール決めのミーティングなど、直接機能の開発のストーリー消化には影響しないものも、開発チームのリソースを利用することになるので、一つ一つのタスクをチケット化することをルールとしました。これらの失敗から、「プロジェクトスタート初期に試行錯誤をする期間が必要であることを関係者と共有する」「開発環境を構築するため、維持するためのタスクもチケット化する」というプラクティスがここで生まれました。とはいえ、いつまでたってもストーリーが消化されないのは、別の原因があるのでKPT（振り返り）をきちんと行い、チームの生産性を上げる施策や改善を繰り返しましょう。

2.市場動向や他社の動向のウォッチと反映タイミング

Before

「管理者が利用するUIは、日常的に使う機能ではないので、機能とUIでは機能を揃える方が優先度は高いよね」
メンバー間の合意で、トレードオフスライダー（相互にトレードオフの関係）を設定し、開発をスタートをしました。ただ3ヶ月後に実際に出来上がったものを冷静に見直してみると、「このUIでは、わかり辛いのではないか」という雰囲気になり、作り変えるコストとスケジュールをどうするかの議論を重ねた結果、残りコストをできる限りUIの一新を行うことを決定しました。

After

また、「この機能、1stリリースでは要らないよね」と話していた機能についても、競合サービスが導入を決めたため、「他社劣位があると、お客様に説明し難い」との営業の声に合わせて、急遽導入を決定しました。この例については、市場動向に合わせて機能開発できるアジャイル開発だからこそ、失敗から早めに方向転換し、改善に繋げられたいい例だと思います。

3.ステークホルダーとの連携不足

KDDIが採用しているスクラム開発において、PO、開発チーム、スクラムマスター以外は、全てステークホルダーという扱いになります。弊社のような規模の会社では、当然ステークホルダーも膨大な数になります。そして、ステークホルダーの中には、多大な影響力を持つ人（商品を企画する際に、作る人、運用する人、売る人と大きく役割を分けた際に、その役割に影響を与える人）もいます。特に導入初期や、プロジェクト初期のアジャイル開発を上手く回すには、この影響力を持つステークホルダーにこそ、プロジェクトに関わってもらうことが重要かと思います。商品を売る人であれば、実際の営業担当だけではなく、営業担当のマネージメント層も巻き込むことが必要です。KDDI Business IDの開発過程においては、ユーザーインタビューの結果を営業担当、マネージメントともに共有し、お客様へ響く提案内容を一緒に作り上げました。

アジャイル開発では、ウォーターフォール開発と違って、製品が徐々に出来上がっていく姿を見せる事が出来るのが強みです。ちょっと変な例かもしれませんが、ステークホルダーに、アジャイル開発の成果物を、孫が育っていく姿を見守るおじいちゃん、おばあちゃんの気持ちになってもらうことが重要です。子の教育は親が責任を持つのだと思いますが、おじいちゃん、おばあちゃんはそれらを温かく支援してもらえますよね。

クラウドサービス開発部　松本です。先日(2015/10/27～30)開催された、OpenStack Summit Tokyo 2015 におきまして、弊社KCPS開発リーダーの前原がCleversafe社のセッションにて講演を行いましたので、その様子をレポートします。

OpenStack Summit Tokyo 2015

OpenStack は、クラウド基盤を構築するためのソフトウェアで、オープンソースとして開発されています。その開発者、利用者、関連ベンダが一堂に会して、技術情報交換、導入事例発表、今後の開発方針の策定等を行うイベントとして、「OpenStack Summit」 が年2回開催されており、今回は東京での開催となりました。Cleversafe 社は同社ストレージ製品のOpenStack対応にも力を入れており、Summit内のセッションとして、Morris社長による同社のOpenStack対応に関する講演が行われました。その講演の中で、弊社前原より、日本国内におけるCleversafe製品の大規模導入事例として、KDDIでの取り組みを紹介させて頂きました。

セッションの模様

Cleversafe John Morris氏

まず、Morris社長から、Cleversafe社自体の紹介、同社製品のOpenStack対応に関する発表がありました。

・画像、動画、遺伝子情報等の非構造化データの爆発的増加

・Cleversafe製品にて、大容量(PBレベル)の非構造化データへの対応が可能

・従来のストレージやクラウド上のストレージサービスと比較しての大幅なコスト削減が可能

・OpenStackへの技術的対応(Swift/Keystone API連携)

また、2015/10/5にIBM社によるCleversafe社の買収が発表されており、講演の中で「IBMの一員として、クラウドの分野へビジネスの幅を広げていく」とのコメントもありました。今後の同社のビジネス展開についてWatchしていきたいと思います。

KDDI 前原 剛

続いて、弊社前原から、KDDIでの大規模導入事例の紹介が行われました。

・コンシューマ向けに、auスマホ内のアドレス帳や写真等のデータをお預かりするサービスを提供

・18億枚の写真、3千万本の動画を保存するマルチペタバイトクラウドに成長

・99.999999999999% (14ナイン) の堅牢性を実現

・コンシューマ向けの実績を活かして、法人向けにもクラウドストレージサービスを開始

プレゼンにて紹介した「なぜKDDIはCleversafe製品を採用したのか？」の部分について、少し深堀して記載させて頂きます。Cleversafe製品を採用した理由は以下の3点になります。

1点目が「拡張性」です。Cleversafe製品はシームレスな拡張性を有しており、無停止かつ無制限に容量を拡張していくことが可能です。従来、マスタ型、P2P型と呼ばれるストレージがあり、マスタ型にはマスタノードが必要であり、そこがSPOFやボトルネックとなる欠点があり、P2P型には容量拡張に制限があるといった欠点がありました。Cleversafe製品はそれらのいいところどりの設計で、欠点がなく、KDDIでもPBレベルの容量拡張を何回か行っていますが、全く問題は発生していません。

2点目が「品質」です。2011年の震災の経験からも、データを分散して保管することの必要性が認識されています。KDDIでは3つのデータセンターにデータを分散配置し、仮に1つの拠点が被災した場合にも、残りの2拠点のデータから復旧可能な設計としています。また、99.999999999999%(14ナイン)という驚異的な堅牢性を実現しています。

3点目が「コスト削減」です。従来のストレージでは、2拠点構成、かつ拠点内でミラーリングを行うため、実容量の4倍のディスク領域が必要となっていました。一方Cleversafe製品では、「Erasure Coding」の技術により、実容量の1.7倍のディスク領域のみ必要となり、大幅にディスク領域のコストを削減することが可能となりました。

終わりに

今回のCleversafe社/KDDIのジョイントセッション、海外の方の聴衆も多く、また講演後いくつか質問も頂く等、活気のある有意義なセッションとなったのではと思います。なお、講演の模様は以下で閲覧可能ですので、併せてご参照頂ければと思います。

Cleversafe – KDDI and Cleversafe present: web-scale Storage for a Data-Driven World

また、OpenStack Summit 全体に関するレポートも別途掲載予定ですのでご期待下さい。

クラウドサービス開発部　松本です。先日(2015/10/27～30)開催された、OpenStack Summit Tokyo 2015 に、クラウド基盤に関する新技術の調査、検討のため参加しましたので、以下にレポートします。

1.OpenStack Summit 概要

OpenStack は、クラウド基盤を構築するためのソフトウェアで、オープンソースとして開発されています。その開発者、利用者、関連ベンダが一堂に会して、技術情報交換、導入事例発表、今後の開発方針の策定等を行うイベントとして、「OpenStack Summit」 が年2回開催されており、今回は初の東京での開催となりました。（Summitは北米／北米以外で交互に開催されており、次回2016春は米国／オースティン、次々回2016秋はスペイン／バルセロナの予定です。）今回、参加登録者は5,000名以上、かつ3分の2以上が海外からとのことで、非常に大規模かつ国際的なイベントとなっています。

2.OpenStack リリースサイクル

OpenStackは年2回メジャーリリースが行われ、各バージョンに対しアルファベット順に名前が付けられます。2015/4に11番目のバージョン「Kilo」がリリース済でしたが、今回2015/10に、12番目のバージョン「Liberty」がリリースされました。なお、2016/4リリース予定の次期バージョンの名称は、日本の地名に由来する「Mitaka」となっています。今回の「Liberty」バージョンでは、アクセス制御の詳細化、NFV用途等の大規模環境への対応、コンテナ管理機能リリース等が新規実装されています。※「Liberty」リリースの解説はこちら。

3.Keynote

Keynote では、OpenStackに関する重要トピックの共有として、以下のような内容が発表されました。

・OpenStack + コンテナ　組み合わせ活用事例

・日本での大規模導入事例（Yahoo! Japan、GMOインターネット、楽天、サイバーエージェント）

・Certified OpenStack Administrator (認定資格) の開始

・OpenStack Superuser Awards の発表（NTT Groupが受賞！）

・OpenStack プロジェクトの再整理　等

上記の中から、「プロジェクトの再整理」について少し深堀りして記載します。
OpenStackは、機能毎に「プロジェクト」として別々に開発が行われており、プロジェクトにはそれぞれかっこいい名前がついています。OpenStackを理解する際、まずプロジェクト名と、その提供機能範囲を覚える必要があります。例えば「Nova」はcompute上のVMを管理する最も基本的なプロジェクト、「Neutron」はネットワークを管理するプロジェクトになります。今回、プロジェクトについて以下の整理が実施されました。

・Core Services (どのような環境でも基本的に必要となるプロジェクト6個)とBig Tent(それ以外の、システム用途に応じて導入するプロジェクト)に分類

・プロジェクト毎に、商用システムでの導入割合、成熟度(5段階)、開発年数の情報を公開

Core Services

・Nova (Compute、利用率98%、成熟度5、5年)
・Neutron (Network、利用率79%、成熟度5、4年)
・Swift (Object Storage、利用率58%、成熟度4、5年)
・Cinder (Block Storage、利用率83%、成熟度5、4年)
・KeyStone (Identity、利用率95%、成熟度5、4年)
・Glance (Image Service、利用率92%、成熟度4、5年)

Big Tent (Core Services以外)

・Horizon (Dashboard、利用率90%、成熟度4、4年)
・Ceilometer (Telemetry、利用率43%、成熟度2、3年)
・Heat (Orchestration、利用率47%、成熟度4、3年)
・Trove (Database、利用率12%、成熟度1、2年)
・Sahara (Elastic Map Reduce、利用率7%、成熟度1、2年)
・Ironic (Bare-Metal Provisioning、利用率9%、成熟度2、2年)
・Zaqar (Messaging Service、利用率1%、成熟度1、2年)
・Designate (DNS Service、利用率9%、成熟度1、2年)
・Barbican (Key Management)、利用率9%、成熟度1、2年)
・上記の他、Manila (Shard File Systems)、Magnum(Containers)、Murano(Application catalog) 等多数のプロジェクトが存在

従来、「自分のシステムではどのプロジェクト（コンポーネント）を使うべきなのか？」、また「そのプロジェクトの開発成熟度はどのくらいなのか？使って大丈夫なのか？」等がやや分かりづらかったのですが、今回プロジェクトの位置づけが整理されたことにより、判断がしやすくなりました。

4.ディストリビューション動向

OpenStack は、オープンソース版（コミュニティ版）をそのまま使うことも可能ですが、ディストリビュータ各社から、独自の機能追加及びサポートを付与した、ディストリビューション版も提供されています。いくつかのディストリビューションについて、ブースの写真と共に、特色やトピックを紹介します。（記載はアルファベット順）

(1) Canonical (Ubuntu)

Canonical社により、Ubuntu (LinuxOS 及びOpenStack)への有償サポートが提供されています。LinuxOSとしてのUbuntuはOpenStack開発環境のレファレンスOSとしても利用されており、その背景から多くの大規模ユーザにて導入されています。Canonical/Ubuntuのトピックとしては、従来のKVMに加え、さらに高集約な仮想環境を可能にするLXD(コンテナ技術)の推進や、Canonical社の既存のツール「Juju/MaaS」と連携し、OpenStackの導入、運用、さらにはアップグレードを自動化する「Autopilot」のリリース、OIL(Ubuntu OpenStack Interoperability Lab) による製品間の相互接続検証の充実化等が挙げられます。

(2) HP

HP(2015/11/1以降は分社してHP Enterprise) は、「HP Helion」のブランドでOpenStackディストリビューション(ホストOSとしての独自LinuxOSも含む)を提供しています。通常版の 「Helion OpenStack」 の他、より信頼性・性能を高めた構成となる「Helion OpenStack Carrier Grade」、OpenStack自体に加えてサービス管理やワークフロー制御等の機能を組み合わせた「Helion CloudSystem」 といった製品があり、ユーザのニーズ、要件にあわせて選択可能です。

Summit直前に、自社運用していたパブリッククラウド「HP Cloud」の提供終了が発表 され、驚きがありましたが、OpenStackに対する取り組みとして、引き続きコミュニティに貢献していくとともに、プライベートクラウドの構築、運用に注力していくとのことです。実際、欧州のキャリア「Telefonica」等、具体的な大型案件も増えているようです。

(3) Mirantis

Mirantis は「Pure Play」をキャッチフレーズにする、OpenStack 専業の企業であり、コミュニティへの貢献度（コードコントリビュート数）も高く、Expedia、NASA等多数の商用環境での利用実績があります。「Mirantis OpenStack」として、自社ディストリビューションを提供しており、デプロイ・運用管理をサポートするツール「FUEL」が特色です。他のディストリビューションと異なり、自社OSはありませんが、システム要件にあわせて適切なOSを選択する自由があります。

(4) Red Hat

Red Hat では、「Red Hat Enterprise Linux OpenStack Platform(RHEL-OSP)」としてOpenStackディストリビューションを提供しています。OS(RedHat Enterprise Linux)、ハイパーバイザ(KVM)、OpenStackをシームレスに開発しており、それらを一括提供することで、統合性、安定性の高い製品となっています。また、RHEL(OS)は10年、RHEL-OSP(OpenStack)は3年の、長期間のライフサイクルサポートがあることも特徴です。また、RHEL-OSPには、配備・管理ツールである「Red Hat Enterprise Linux OpenStack Platform Director」が付属しており、自動クラウドインストール、ベアメタルリソースの自動プロビジョニング等の機能により、運用担当者の作業負荷を軽減することが可能となっています。

(5) VMWare

VMWareは、「VMWare Integrated OpenStack(VIO)」という名称でOpenStack ディストリビューションを提供しています。VMWare用のディストリビューションであるため、KVMには対応していないものの、vSphere、NSX、Virtual SANといった、同社製品との統合利用が簡単に行えるような設計となっています。例えば、VMWare製品の性能、多彩な機能、高可用性等のメリットを活かしつつ、OpenStackのAPIをシステム利用者向けに提供したい、というような利用シーンに適した製品となっています。

5.その他

OpenStack Summit では、「Market Place」として、ディストリビュータ、SDNやストレージ等の関連製品ベンダ、コンサル/SI事業者等がブース出展する場が設けられており、今回は神社の縁日的な雰囲気となっていました。

日本OpenStack ユーザ会としてもブース出展があり、日本のユーザ会の活動や会場（品川）周辺の観光情報等を紹介しました。少しだけ説明員としてお手伝いさせて頂き、ブースの前で足を止めた海外からの方に、手作りの「品川グルメマップ」を配布し、ラーメン等にチャレンジするようお勧めしました。

6.終わりに

国内での導入事例も増加し、また、コンテナ対応等の機能拡張も非常に速いスピードで行われており、OpenStackはますます勢いを増していることが感じられました。OpenStackコミュニティ及び業界の動向や開発状況について、引き続き確実に押さえて行きたいと思います。また、KDDIとしての取り組みについても別の機会にご紹介することができればと思います。

こんにちは、KDDI Business IDの開発を担当している中嶋です。KDDI Business IDは万が一の災害によりデータセンターが被災した場合でも安心して継続利用していただけるようにKDDIクラウドプラットフォームサービス（以下、KCPS）の東日本サイトと西日本サイトで冗長構成をとっています。その冗長構成を実現する方法として、７月からKCPSの拡張ロードバランサーとして提供開始しているA10ネットワークス株式会社の「vThunder ADC」のGSLB（広域負荷分散）機能を利用しています。今回は、その詳細な内容についてご紹介したいと思います。

vThunder ADCの特徴

■GSLB機能
GSLB機能を利用することにより、複数拠点による冗長構成が構築でき、サービス可用性が向上します。ビジネス継続性 (BC) ソリューションと障害時復旧 (DR) ソリューションが実現できます。GSLB機能を実現するためには、vThunder ADC内でDNS機能を持っていますが、キャッシュDNSサーバの機能はなく、単純にAレコード、MXレコードを返す仕組みとなっているため、脆弱性が発生しにくい仕組みになっています。

■WAF機能
Webサーバの脆弱性、Webアプリケーションへの攻撃から保護し、情報漏えいやサイト改ざんなどのリスクを大幅に削減します。

■DDoS対策
サーバ前段でDDoS攻撃をブロックして、サーバの保護、正常トラフィックの保護を行い、サービスの継続性を確保します。

■運用が容易
分かりやすいGUIと豊富なモニタリング機能により運用が容易です。また、定期的なライセンス更新や、長期サポートにより定期的なバージョンアップが不要なため、運用コストが削減できます。

GSLB導入概要

KDDI Business IDをマルチサイトで構築するには、認証画面を表示するリクエストと認証リクエストを同一サイトで完結させる必要がありました。初めはDNSラウンドロビンを利用してサイト冗長しようと思いましたが、Keep-Aliveで認証トランザクションを同一サイトで完結させようとしても、通信経路にプロキシ等があってKeep Aliveが正常に機能しないケースもあり、難しいことが分かりました。そこで、KCPSが提供を計画していたGSLB機能を持った「vThunder ADC」をいち早く導入することを決めました。導入後はマルチサイトで安定した認証サービスを提供することができ、一層安心・安全に利用していただくことができるようになりました。

【vThunder ADC導入構成】

GSLB設定方法

KDDI Business IDにて実施したGSLBの設定について紹介します。権威DNS Serverで設定した内容を(1)で説明、vThunder ADCで設定した内容を(2)〜(5)で説明しております。

※図中の(2)(3)(4)はvThunder ADCの設定のどこの情報（IPアドレスなど）を設定しているかを意味します。

■権威DNS Server側への設定
(1)権威DNS Serverから、vThunder ADC (GSLB)に名前解決を委譲するための設定をします。
・NSレコードでネームサーバの設定
・ネームサーバのドメイン名のAレコードを設定（東日本および西日本のGSLBのIPアドレスを設定）

例：　www.example.comをアクセスFQDNとした場合、example.comのゾーンのレコードは以下のようになります。

■vThunder ADC (GSLB)への設定
(2)DNS バーチャルサーバの作成
権威DNS ServerからのDNSクエリーを受け付けるためのバーチャルサーバの作成をします。

• KDDI Business IDでは東日本と西日本にGSLBを設置しているため、東日本と西日本のバーチャルサーバの設定をしました。

(3)サービスIP設定
受け取ったDNSクエリーに対して応答するサービスサーバのIPアドレスの設定をします。

KDDI Business IDではサービスサーバも東日本と西日本でサイト冗長を行っているため、東日本と西日本の各サービスサーバのIPアドレスを設定しました。GSLBからサービスサーバに対するヘルスモニタも本項目で設定します。

(4)サイト設定
KDDI Business IDでは東日本と西日本のサービス側のサイト情報を設定しました。

(5)ポリシー設定
負荷分散のポリシーの設定をします。

東日本と西日本のサイトにどのような条件で振り分けるのかをここで設定します。Round Robinや地域で振り分けるGeographic等のメトリックを選択できます。上位のメトリックが優先されます。
メトリックの「Health Check」はヘルスチェックがNGとなったサイトには振り分けないような動作になります。 

導入ポイント

■永続性（persistence）
マルチサイトの永続性は、DNSにて同じサイトへの永続接続、負荷分散にてサーバへの永続接続の2つを実現する必要があります。今回はGSLB機能であるDNSによる同じサイトの永続接続について説明します。vThunder ADCのGSLB機能を導入しただけでは、サイトの永続接続ができるわけではありません。DNS問合せのタイミング（TTLの期限切れ）で、異なるサイトへアクセスする可能性があり、永続性が保てなくなることがあります。

それを解決する方法として、vThunder ADCのGSLB機能は、DNS問合せするソースIPアドレスにより回答するサイトが一意になるような機能があります。一意にする方法として以下の２つの方法がありますが、KDDI Business IDでは、構成をシンプルにするために「1.」の方法を採用しています。

1.vThunder ADCでユーザが作成したソースIPアドレスと回答するサイトのテーブルで永続性を確保

・アジア地域は東京サイトへ、ヨーロッパはロンドンサイトのように近いサイトに接続できるようにユーザが設定できる。
・サイトのvThunder ADC間で永続性を確保するための通信が不要。

2.vThunder ADCが問合せ元のソースIPアドレスを管理し、回答するサイトが一意になるようにして永続性を確保

・ソースIPアドレス毎に回答するサイトの設定が不要。
・サイトのvThunder ADC間で永続性を確保するための通信が必要。
・サイトの負荷状況により、接続先のサイトを自動的に振り分けることが可能。

ここで1つだけ注意事項があります。vThunder ADCのGSLB機能で永続性を確保するために利用されるソースIPアドレスは、クライアントIPアドレス（1）やDNS問合せを受けるIPアドレス（2）ではなく、vThunder ADCへの問合せで利用されるDNSサーバのIPアドレス（3）です。また、DNSサーバによっては、問合せで利用されるIPアドレス（3）が複数あることもありますので、注意が必要となります。

■フォールトトレラント
vThunder ADCのGSLB機能は、Aサイト、Bサイトを定期的に稼働状態かを確認するヘルスチェックを行っており、Bサイトで障害が発生すると、ヘルスチェックによりNGとなり、DNS問合せには、Aサイトのみを回答することとなり、それによりクライアントからのサーバへのアクセス先もAサイトのみとなります。Bサイトへアクセスしていたクライアントは、Aサイトへアクセスすることとなりますので、一時的に永続性がなくなりますが、サービスは継続利用することが可能になります。

最後に
vThunder ADCを利用することで、KCPS上で簡単にサイト冗長を構成することができますので参考になればと思います。ますます進化していく、KDDI Business IDとKCPSの今後にご期待ください。

Office 365 with KDDI担当の山中です。10/28(水)～29(木) の2日間、チェコ・プラハにて、Office 365パートナーをはじめとしたMicrosoftのパートナーイベント 「Microsoft Cloud Service Provider Summit 2015」（以下、「Summit」）が開催され、世界各国から計77社のパートナーが参加しました。そのSummitにて行われた2015年の「Partners Award」の表彰で、日本からはKDDIが唯一「Voice of the Partner」を受賞しました。

この「Voice of the Partner」は、Office 365の販売実績に加え、ネットワーク、モバイルを絡めたKDDIならではの販売モデルやマーケティング活動が評価されたものです。これまで、KDDIの取り組みを支えていただいたみなさま、そして実際にKDDIからOffice 365を導入いただいたお客さま、本当にありがとうございました！

Microsoft Cloud Service Provider Summit 2015

Summitでは、Microsoft社によるKeynoteを皮切りに、パートナー各社による講演が行われました。日本からはKDDIが講演を行い、クラウドサービス企画部長の藤井から、KDDIのOffice 365販売・マーケティングに関する取組みをお伝えしました。

「Voice of the Partner」の表彰式

Summit 1日目の夜には、2015年におけるパートナーの取組みを表彰する懇親会が開かれ、世界各国のパートナー6社がAwardを受賞しました。その6社のうちの1社がKDDIです。

左からMicrosoft Senior Director, WW Operator Business Cloud Services Mark Rice氏
KDDI クラウドサービス企画開発部 マネージャー 山中 紀昌
KDDI クラウドサービス企画開発部 部長 藤井 彰人
Microsoft Vice President, WW Hosting & Cloud Services　Aziz Benmalek氏

 進化し続けるMicrosoftのクラウド

Office 365をはじめとするMicrosoft社のクラウドは、Fortune500企業のうち80%が利用している等、契約社数もますます増加し、サービスの進化スピードも非常に速いです。この勢いは、Summitでも身をもって実感したところです。このすさまじい勢いのOffice 365や、Office 365に必要不可欠なモバイル＆ネットワークの合わせ技にご興味がある方はぜひ、KDDIまでお声がけください！

はじめまして。ID関連を担当しております、クラウドサービス企画部　小畑です。少し前になりますが、KDDIは2015年11月10日「OpenID Summit Tokyo 2015」にてOpenID Foundationにボードメンバーとして参画したことを発表しました。今回は、イベントの模様をレポートしたいと思います。開催概要はこちら。
OpenID Summitは毎年開催されておりますが、日本開催は4年ぶり2回目となります。サミット参加者数　約330名に対して、OpenID Foundationメンバーや認証界の著名人たちが、今後のID認証に関わる技術動向、認証方法を実例と共に発表されました。OpenIDとは、簡単に言えばURLをIDに利用する認証プロトコルです。本イベントではOpenID 2.0の進化系であるOpenID Connectを中心に話がありました。ちなみに、KDDI法人向け認証サービスである「KDDI　Business ID」はOpenID Connectを採用しており、お客様サービスをセキュアに連携し、SSO(シングルサインオン)を実現しております。新しい技術を取り入れながら、常にお客さまが安心して利用でき、満足のいくサービスのご提供を心がけています。

KDDIが認証プロトコル標準化団体である、OpenID Foundationのボードメンバーに日本キャリア初の参画

調印式にて：（左）OpenID Foundation Executive Director 　Don Thibeau
（右）KDDI 商品統括本部　統括本部長　執行役員　山本　泰英

KDDIが認証プロトコルの標準化団体であるOpenID Foundationのボードメンバーに日本キャリア初の参画となった事は、プレスリリースとイベントで公表しました。何故、KDDIが認証プロトコル業界で評価されたのか？それは、現在約2,500万契約となったコンシューマ向けID認証サービスauIDがID　Federation（様々なアプリを「1ID」でセキュアに便利に認証連携する仕組み）を使ったモバイルビジネスモデルで成功している事が大きかったようです。日本の大規模なモバイルビジネス（認証連携）は世界で注目されています。欧米諸国でのモバイルビジネスは通話料収入でビジネスが成り立ってきましたが、スマートホンのシェアが大きくなるにつれてビジネスモデルが変わってきています。日本でも同じですね。その対策として、海外では通話だけでなくサービス連携に力を入れ始めており、大きく先行している日本のビジネスモデルが参考にされています。「家族割」と言った通信事業者の属性認証サービスも世界のビジネスモデルで実例が殆ど無く、日本が先行して進めているサービスです。KDDIはモバイルビジネスで培った技術でお客様の情報を安全に預かって参ります。

テクニカルフェーズからビジネスフェーズへの転換期

前回のOpenID SummitではOpenID Connectが標準化（2014年2月）される前であり技術的な話がメインでしたが、標準化され1年たった現在では具体例が増えてきてます。数多くの実例が立ち上がっており、ビジネス転換期が来たといって良いでしょう。今回のサミットでは各界の著名人が一堂にあつまり、ID技術の活用例、OpenID Connect に関する技術的な議論、IoT (Internet of Things) や FinTech への技術適用などの事例紹介等から良いヒントが多くあったと思います。

Keynoteでは様々なサービスが連携することで認証機会が増大し、それに比例してリスクも大きくなったと話されていました。世の中にクラウドサービスがすごい勢いで増えてきているのは皆さんも実感されていることと思います。ビジネス機会が増えるのは良い事ですが、もう一方で連携先のIDの信頼性があるかどうかを正しく確認しなければならないと伝えています。実例では「SNS認証の乗っ取り」や「クレジットカード決済時の番号盗用」があります。従来からあるクレジットカードのスキミング被害は、既に被害全体の中では低い位置づけであるのが事実です。今までのハードウェアで起こる被害から、インターネットというソフトウェアで認証を行う入力された情報を信用することによる被害にシフトしているのです。このような傾向から、連携先のIDが不正かどうかを検知する技術が必要とされており、世の中のアプローチが変化してきました。今まではログインパスワードをサイトごとに変更するように呼びかけていましたが、パスワードの全て覚えるのは困難です。重要なのはクラウド化する流れの中で、「利用されているIDが正しいかをどう判断すべきか」、「ID連携で引き渡された相手信頼性をどのように担保するのか」をしっかり考える事です。ID／Passwordのみで相手を信じてはいけないと言う事です。

ID/PWを使わないログイン方法。IoT時代の認証技術とは?

大変興味深い内容として「ID/Passwordを使わないログイン」について慶応義塾大学 増井俊之教授のKeynoteセッションがありました。私がSonyErricssonのケータイ担当していたこともあり、POBoxの生みの親である増井教授の話はとても引き込まれました。資料にもありますが、今回の内容は「学生時代の思い出写真」や「旅先の写真」を選択すると言った他人が知りえない内容の組み合わせでログインするというもので、今までとは異なるアプローチとなります。「記憶しなければわからないものは記憶しにくいが、体験に基づいた記憶は忘れない。」確かにその通りですし、また違った切り口で見るとログインすること自体が楽しくなりますよね。ユーザー経験に裏付けられた、直感的に反応できるUserExperience（UX)をがきっと主流になるでしょう。KDDIでも多要素認証の一部として検討していきたいと思います。

技術ではなく、ビジネスでIDを考える。

そして、次は我らがKDDI クラウドサービス企画部長である藤井彰人の登壇です。「IDの信頼性確保と接続はできるようになったが、今後はビジネス面でのさらなる活用について」をテーマに講演しております。「ID連携は、auスマートパスのように求める人と提供する側の利害が一致するからこそ成功する。」と技術先行でなく、ニーズに対して技術力でカバーする必要性をお伝えしました。

まとめ

いかがでしたでしょうか？今まではIDや認証イベントでは、シーケンスや技術論が多く語られ、ビジネスに導く話まで議論がほとんど無かったと思います。前回までとの大きな違いは、約330名もの参加者がIDの接続（ビジネス）に関心をもち、スピーカーはビジネスに直結する実例を上げながらクラウド化の勢いを話しました。クラウド化の流れは速いです。KDDIは、OpenID Foundationに加盟したことにより、常に先端の情報を取り入れてビジネス化し、便利で安全なサービスを提供していきたいと思います。

こんにちは。KCPSオブジェクトストレージサービス開発担当の本江です。今回はKDDIの法人向けオブジェクトストレージサービスである、KCPSオブジェクトストレージ開発でこだわった、オブジェクトストレージの堅牢性についてお話したいと思います。

みなさん、「堅牢性」という言葉を聞いてピンとくるでしょうか？
一般的に、データベースやファイル更新などのリアルタイム処理が求められるシーンではシステムの可用性やI/O（※インプット／アウトプット）性能が重視される傾向にあり、ブロックストレージやファイルサーバがよく利用されます。これに対し比較的I/O頻度が少なくバックアップなどデータを大切に保護保管することが求められるシーンではオブジェクトストレージがよく活用され、主に耐久性・信頼性・機密性、完全性などが重視される傾向にあり、これらを総称したものが堅牢性という言葉でよく使われます。分かりやすく例えると、可用性はサービスが停止しないことを表す指標なのに対し、堅牢性はサービスが停止してもデータが無くならないことを表す指標と言え、「堅牢性が高いシステムだと、安心してデータを預けることができる」、ということにつながります。

クラウドサービス開発部では以前からオブジェクトストレージを利用していましたが、より高い堅牢性が実現できる製品の選定・評価を行い、Cleversafeストレージの採用に至りました。拡張性、Write/Read要求処理性能、Write処理時のコミットから複製完了までのプロセス、ディスク盗難時のデータ漏えいリスクなど様々な観点で評価を行いました。別記でCleversafe導入について触れていますのでよければご参照ください。

高い堅牢性を実現する設計

高い堅牢性を実現できるCleversafeのシステム設計についてお話します。Cleversafeは分散保存方式のオブジェクトストレージで、データを暗号化しパリティビットを付加したものを複数ノードに分散保存します。KCPSオブジェクトストレージでは、１つのストレージプールを18のストレージノードで構成し、18ノード中、11ノードが稼働していればデータの読み出しが可能な設計とし、国内3箇所のデータセンターに6ノードずつ配置しています。これは1つのデータセンターが稼働しない事態となってもデータを失わないという設計思想に基づいています。

また、1つのストレージノードには数十本のハードディスクが搭載されており、1つのスライスデータは各ノード内の任意のハードディスクに保存されるため、ノードが故障してもデータが無くなることはなく、実際には、あるデータのスライスデータが保存されたハードディスクが、8ノードに渡って8本同時故障しなければデータロストすることはありません。

容量拡張時は、ストレージプールを追加作成し、論理的に拡張する構成を取っています。データの格納先ストレージプールは、ゲートウェイノードで書き込みリクエストごとに任意に選択され、保存されるデータはある1つのストレージプール内のノードに分散保存されるため、容量拡張が容易となっています。また、ストレージプールを並列に増やしても各ストレージプール内のノード数は一定なため、応答速度の低下なく堅牢性を維持することができます。

14ナインとは？

99.999999999999%と表現される堅牢性ですが、１年間にデータロスする確率を示しています。堅牢性の計算は、ストレージプールを構成する総ノード数、読み取り可能となるノード数、ノードに搭載されるハードディスク本数、ハードディスク容量、ハードディスクの故障率やハードディスク故障時のデータ退避／復旧に関する係数、などから求めることが出来ます。例えばストレージプール内のノード数を増やすことで堅牢性を高くすることも可能ですが、その分お客様のコスト負担増につながってしまいます。KCPSオブジェクトストレージでは、堅牢性／拡張性／コストのバランスから、18ノード3拠点分散のストレージプール構成を決定し、この構成から導き出される堅牢性が、99.999999999999%（14ナイン） となります。一般的なインターネット型クラウドストレージでは、99.999999999%（11ナイン）と表記されていることが多く、この場合、「1億個の実データを10年間保存した場合に１個データがロストする確率が0.01%である」と言い換えることが出来ます。お客様によっては実データを小サイズに分割するなど様々な方法で保存され、お預かり期間も長期にわたると想定されます。万一の確率を限りなく低くすることがサービスプロバイダとして重要であると考えます。14ナインの場合、「1億個に１個データが10年以内にロストする可能性」は0.00001%まで下がると言え、より高い安心感をお持ちいただけるかと思います。

数値に表れない堅牢性

堅牢性には、機密性、完全性という意味合いもあります。KCPSオブジェクトストレージはキャリアクラウドとしての強みを活かした閉域網でのセキュアアクセスサービスをご提供しています。詳細は、別記をご参照いただければと思います。簡単にご説明しますと、お客様のデータへはお客様の閉域網からしかアクセスできない設計としており、万一お客様のご利用IDが第三者に漏えいしても、お客様閉域網以外の外部ネットワークからはアクセスできない仕組みとなっています。昨今のクラウドストレージはインターネット経由のアクセスが多い中、データロストしないこと以外にもより安全なアクセス環境も設計コンセプトとして開発しております。

最後に

いかがでしたか？オブジェクトストレージと求められる堅牢性について、なんとなくご理解いただけましたでしょうか。KCPSオブジェクトストレージでは、お客様に安心安全にデータを預けていただけるサービスとなるよう、品質づくりを行っています。インターネットクラウドストレージ利用に不安をお持ちの方は、是非KCPSオブジェクトストレージをご検討いただければと思います。安心してください！分散保存してますから！！

皆様こんにちは、アジャイル開発＆DevOps推進担当の川上です。アジャイルは成長、変化に強い開発手法ですが、今回は新規のサービス開発だけではなく、既存業務やシステムの改善とアジャイルの良い関係について書いてみたいと思います。

部門横断にその道のプロを召集し、改善点を抽出

写真は、あるプロダクトの改善プロジェクトでユーザーストーリーマップを作成しているところです。（ユーザーストーリーマップについては、Jeff Patton氏の著書、ユーザーストーリーマッピングなどに詳細が記載されています）

写真に全員は映っていませんが、このユーザーストーリーマップの作成には、総勢10人のメンバーが集まって、ああでもない、こうでもないと議論しています。プロダクトオーナー、開発部門、運用部門、業務部門というメンバーでお題は「如何に早くお客様にサービスを提供する為に、バックヤードの業務部門はどのような改善を行えば良いか？」というものです。ユーザーストーリーマップの詳細説明は割愛しますが、ポイントは「業務に関わる部門のメンバーが全員参加しているか」という点になります。プロダクト（サービス）を良くする為に、今の業務の棚卸しと、改善ポイントの洗い出しを一緒にやることで、全員が同じ背景を共有した状態で、議論が出来ると活発な意見が出やすくなります。また、皆が壁のポストイットを見て話をしている点から分かるように、課題を洗い出すことに集中します。よく会議でありがちな、「誰々が悪い」という対立を生みづらい環境を作り易くするのです。

KPIを明確にしよう

改善のユーザーストーリーマップの1枚のチケットの記載内容には、ちょっとした工夫があります。ユーザーストーリーマップの各アクションで、「どれくらいの時間がかかり、月にどれくらいの件数があるのか」を明確にすることです。これを書く事によって、「今、自分たちがどの作業に時間を取られているのか」というのが明確になります。さらに言うと、どのアクションを改善するのが最も効果的かを定量的に判断出来る様になります。月に沢山件数があって、時間も掛かるアクションを改善すべきなのは誰の目に見ても明らかですよね。
ただ、その情報を、１人のメンバーで全てを書き出すことは困難です。ですから、業務を深く知っているメンバーがそれぞれの知識を全て出してもらうのです。また、こうやって定量化すると、優先度に納得感が出るという効果もあります。自分の業務を軽くして欲しいと誰もが思いますが、残念ながらリソースは有限です。その中で、改善効果が高い物から実施するという方針を取った時に、時間という効果が明確になりますよね。気持ち的なところは置いておいて、明確な判断規準があるということは、物事を決定する際に、大きなメリットになります。

小さな改善の積み重ねが大きな成果となる

1週間や、２週間で出来る改善というのは非常に少ないかもしれません。また、システム開発が必要な場合は、数ヶ月かかる場合ももちろん有ります。しかし、小さな改善を一つずつ積み重ねることが大きな成果に繋がります。リーンやアジャイルの小さく作って、大きく育てる考えはここでも活かされるのです。新規のサービス開発だけではなく既存の業務や、システム改善についてもアジャイルのアプローチは有効です。皆様も是非トライしてみてはいかがでしょうか？

アジャイル開発、DevOpsの推進担当の川上です。本日は、KDDIにてアジャイル開発、DevOpsの取組みを始めるにあたりアドバイザーとしてもご協力頂いた、現在、マイクロソフト　コーポレーションDevOpsエヴァンジェリストである牛尾　剛さんとDevOpsの意義について議論した内容を掲載します。

DevOpsの定義、どう捉えるか？

川上：DevOpsの概念は広いので説明が難しいですが、あえて一言でいうならば、どう説明されていますか？

牛尾氏：一言で言うと、「ビジネス、Dev(開発)、Ops（運用）が協力してソフトウェアのライフサイクルを改善し、ビジネス価値の創出を改善する活動」と説明していますね。

川上：ではビジネスの価値を高めるために、小さく早くスタートするというLeanや、Agileの概念をより広げたイメージですね。

牛尾氏：そう捉えてもらっていいです。Opsも入って、そこも改善しないと行き届かないんですね。DevOpsの歴史を紐解くとリリースサイクルの改善というテーマがあり、頻繁に安全にリリースしないと競争に勝てない。Dev-Opsの間が一番の溝で、日本の場合は別会社だったりする。難易度は高いがそこを合致させることで効率がぐんと上がります。ビジネス価値を生み出すようなサイクルの速さを生み出していくことができるようになるんですね。

川上：今までの一般的なウォーターフォールをやっていたら、リリースまでに1～2年はかかりますもんね。それではとても競争には勝てません。現在KDDIでもお客様にモバイル提供するまでにたくさんのアクティビティをこなさないと端末を提供出来ない状況にあり、開発だけではなく営業、企画、運用、マーケティング部門を巻き込んで根本的な問題の洗い出しを行っています。技術、システムを改善すればできるものもあれば、組織を変えないと出来ないものもあり、この取組み自体がDevOpsなのかなと思ってますね。日本では、DevOpsと言えば開発中心の話と捉えられ、営業や企画の人は無関心だったり、そこがなかなか変わっていかない、DevOpsが浸透しない理由でもあるのかなと思いますね。

牛尾氏：なるほど、良い視点だと思いますね。僕の意識の中でもDevOpsは3年くらいに流行って今はすたれているんですよ。当時は技術中心で、Infrastructure codeを書けるようなカッティングエッジな人々がChefを試して面白いな～と感じていたが、日本では継続しなかったんですよね。もう飽きられている。USでは現場でChefが利用されていて、そこが大きく違う。メリットはあるが、そこがまだ理解されていない状況ですね、日本は。

早くリリースしてフィードバックを得る「アジャイル＋α」がこれからは必要。

川上：日本企業、また大企業になるほど、DevOpsの実現は難しいと感じていますが、海外ではどのような成功事例がありますか？

牛尾氏：DevOps Enterpriseというイベントで発表された事例で全米2位のリテールカンパニーが、「10 deploys per day」を実現しています。3か年計画とかを今まではやってきたけど、スピード感、要件が厳しくなってくるので、今ではまず、デプロイして意見を募る方法へと切り替えました。Canary testingという手法で、1部のお客様だけに実際のプロダクションをリリースし、技術的なものだけではなく、「儲かるのか」「revenueがスケールできる状況にあるか」「お客様は使ってくれているのか」などプロダクションからデータをとって活かしていくほど発達しています。アジャイルのように「いかに効率的に開発できるか」から一歩進んでプロダクションを早くリリースしてフィードバックを得ることが今は重要になってきているんだと思いますね。それも含めないとうまく回っていかないし、ビジネスバリューがでるかわからないですからね。「アジャイル＋α」がこれからは必要だと思いますね。

川上：上の人のコミットがあれば、できそうな話ではありますね。小さな投資から進められるといいですね。1ヶ月単位でやってみて、反応がわかるなら継続していこうじゃないかと。気軽にチャレンジできればいいですね。

「大企業で小さなチームが運用できれば、スタートアップのテクニックが有効」

牛尾氏：これからのエンタープライズ企業として、KDDIには先陣をきってもらいたいですね。最近の大手企業は、スタートアップにやられっぱなしじゃないですか。それはスタートアップの方がDevOpsが浸透しているからというのも理由の一つだと思うんですが、大企業でスタートアップのように小さなチームを運用できれば、スタートアップのテクニックが有効なわけですよ。そうなるとリソースが潤沢にある大手が断然、有利となってくるわけです。KDDIも大企業でありながら、チーム自体は小さいもので回してますよね。小さいチームを組み合わせて大きなプロジェクトを成功させていってもらいたいと思います。

川上：大手企業だと、組織の壁などもあり、やる前に諦めている気がしますね。それは勿体ない。実際にやれば出来る事は数多くあるし、上のコミットが必要であれば、コミットを取りに行けばいいし。何でも前向きに考えればできるんじゃないかと、実際にKDDIでのアジャイル開発をカタチにしてきたので実感してますね。

KDDI のDevOps、アジャイルの取り組み、「KDDI方式」を作りたい

川上：KDDIがアジャイルを進めていく中で、今までのビジネスガイドラインの適用が出来なくなり、ウォーターフォール開発の際には開発部門だけで検討していたガイドラインも、企画、運用のメンバーにも入ってもらわないと回らなくなってきました。ガイドラインを適用しないとそもそもリリースできないし、ガイドラインは運用部門も見なければいけないから、無視するわけにはいかない。ガイドラインをトリガーに3部門のチームができた感じです。うまいこと作ってしまえば皆が協力して従うしかないよねと。これが成功すれば、自動でDevOpsできるんじゃないかと企んでます。

牛尾氏：いいですね。ＫＤＤＩのアジャイル、DevOpsの導入はエンタープライズ企業の星だと思うんですよ。ある意味、圧倒的。スタートアップあがりではなく、そこまでやっている企業はないと思う。本質を理解して、適切なメンバーも集め、テスト駆動や自動化もしっかりやって、マインドセットで企画の人を巻き込み、そこまでやっている日本のエンタープライズ企業で他にあるのかな？という勢い。現場のパッションもあるし、上のコミットもある。揃っているというのが大きいかもしれないし、ビジョンが素晴らしいですよね。

川上：トヨタ生産方式を生み出したのがすごいと言われてますが、我々はKDDI方式のDevOps、アジャイルを作りたいと。日本のアジャイルと言えば、KDDIと言われるぐらいまではなりたいというパッションを持って皆やっていると思いますね。今後ともアドバイス宜しくお願いします。本日はお忙しいところありがとうございました。

日本マイクロソフト株式会社　品川本社へ伺いました。

牛尾 剛さんプロフィール：
マイクロソフト コーポレーション/シニア テクニカル エバンジェリスト DevOps

Google Apps for Work ™ (以下 Google Apps ) 担当の石井です。街はすっかりXmasですね。先日12/2(水)、そんなXmasイルミネーションが素敵な Google 六本木オフィスで 開催された Google for Work Japan のパートナーイベント 「 Partners Get Together 2015 」 で、KDDIは「 Google for Work Japan Partner Award 2015 」 を2部門受賞しましたので報告します。

まず、KDDIが 「 Google Apps for Work – Sales Award 」を、そしてKDDIまとめてオフィスが「 Google for Work – Leadership Award 」をそれぞれ受賞しました。主に大企業層のお客様を担当するKDDIと、主に中小企業層のお客様を担当するKDDIまとめてオフィス のダブル受賞で、企業規模に関わらず、お客様ニーズに応じた幅広い Google Apps ／ Drive for Work の提案と導入の実績を評価いただき、大変うれしく思っています。
これまでのKDDIの取り組みを支えていただいたパートナー様、そして実際に  Google Apps ／ Drive for Work を導入いただいたお客様に改めて感謝の気持ちをお伝えしたいと思います。

■グローバル パートナー アワードに続き、国内パートナー アワード 2部門受賞

今年2月 Global Award  国内で唯一 受賞　　　 そして今回 国内 Awardを ダブル受賞

Google Japan Google for Work 責任者  阿部 伸一氏(両写真 右側)
KDDI 営業推進部 クラウド推進グループ  マネージャー 藤井 健(左写真 左側)
KDDIまとめてオフィス  営業推進部 クラウド営業グループ  グループリーダ 高田 聡(右写真 左側)

「KDDIと共に ” Go Google ”しませんか？」

今年2月サンディエゴでの「 Partner of the Year 」受賞に続き、今回の国内での「  Google for Work Japan Partner Award 2015 」の2部門受賞でKDDIでの Google Apps  提案の勢いはますます加速しています。これからもますます進化する Googleの先進テクノロジーとKDDIのクラウドサービスに少しでも興味がある方は是非KDDIまでお声掛けください。2016年もよろしくお願いします。

Google,  Google Drive, Google Apps および Gmail は、 Google Inc. の登録商標または商標です

KDDIクラウドプラットフォームサービス（以下、KCPS）のサービス運用リーダーの野崎です。
KCPSの2015Q4稼働率（※）は99.999998%でした。

（※）稼働率＝月間VM稼働時間累計／（月間VM稼働時間累計＋月間VM故障時間累計）ただしメンテナンス時間を除く

19ヶ月連続で99.999%達成

2015Q4の故障部位内訳は、サーバ・ホスト故障のみで、ストレージ故障、仮想ネットワーク故障は発生しておりません。ここにも稼働率アップの要因が表れています。

2年前の度重なる故障で多くのお客さまへご迷惑をおかけした、その教訓を生かしサーバ・ホスト、ストレージおよびクラウド管理サーバー群の品質改善を継続的に実施し、19ヶ月連続で99.999%（ファイブ・ナイン）、また2015.11と2015.12は単月100%を達成することができました。ただこの実績に一喜一憂するのではなく、より一層気を引き締めてKCPS運用に取り組んでまいります。

Service Organization Controlの取り組み

品質改善活動を基盤とし、さらにお客さまのクラウドサービスに対する可用性、セキュリティ確保のニーズに対応するため、第三者保障であるService Organization Control（以下、SOC）報告の取得にチャレンジしています。2015年度取得準備中のSOC2ではKCPS運用業務について米国公認会計士協会が策定した判断基準（クライテリア）にもとづき、セキュリティ、信頼性、可用性、機密性、インテグリティ、プライバシーについて内部統制が保障されます。現在KDDI一丸となって内部統制のデザインと実行監視に取り組んでいます。これにより、引き続きお客さまに安心してKCPSをご利用していただけると考えております。

“すべては稼働率アップのために”

本年もKCPSをどうぞよろしくお願いいたします。

みなさまこんにちは、ヴェムリ ムルティです。私はいまKDDI クラウドプラットフォームサービス（以下KCPS)の魅力を皆さまにお伝えすることをミッションとして、Cloud Expoなどで講演を行なっておりますので、私の講演をお聞きなった方もいらっしゃるかと思います。KCPSに関しては、クォーター毎に稼働率を公開するなど、本Blogに様々な記事を投稿しておりますので、お馴染みの方も多いと思いますが、オンラインセミナーのご案内です。

お気軽にオンラインで受講できるセミナーを開催します

今回、専有サーバもオンデマンドで構築できるKCPSの魅力を、デモンストレーションやKDDIのクラウド戦略を交えてご紹介するセミナーを開催することになりました。ただ、東京などの特定の場所でセミナーを開催してしまいますと、興味はあってもなかなか会場まで行くことが難しい方もいらっしゃると思いますので、今回はオンラインで開催させていただきます。パソコンとインターネット環境があれば、会社のお席などでお気軽に受講いただくことが可能です。

オンラインセミナーの開催概要は以下のとおりです。

日時：2016年2月2日（火）15:00～15:45
場所：オンライン（画面はパソコンで表示し、音声はパソコンのスピーカーorイヤフォンで出力します）
講師：KDDI株式会社　クラウドサービス企画部　ヴェムリ ムルティ
KDDI株式会社　クラウドサービス企画部　和田 圭介（デモンストレーション部分）
コンテンツ：
－KDDIのクラウド戦略を含むKCPSのご説明とユースケースのご紹介
－KCPSのカスタマーコンソールのデモンストレーション（サーバの構築、見える化ツールのインストール／デモ など）
－KCPSオブジェクトストレージのご説明とユースケースのご紹介
－KCPSオブジェクトストレージのカスタマーコンソールのデモンストレーション
（Bucketの作成、バックアップツールのインストール／バックアップのデモ など）
参加費用：無料 (事前登録制)　※詳細・お申し込みは、こちら。

ご好評頂いているAdmin Consoleのデモを実施します

今回のオンラインセミナーでは、昨年リニューアルして、とても使いやすくデザインもクールになったと評判をいただいている、KCPSのカスタマーコントロール「Admin Console」のデモもふんだんにご覧いただけます。KCPSの使いやすさ、クラウドの特長であるオンデマンドの構築を実演させていただきますので、クラウドでのサーバ構築をご検討されている方などに特におススメです。また、Admin Consoleでは、サーバログの”見える化”や、インスタンス構成の”見える化”など、様々な”見える化”を実現していますので、今回のセミナーをとおして”見える化”の素晴らしさも実感いただけると思います。

みなさまのご登録をお待ちしております

大切なことですのでもう一度申しますが、セミナーのお申し込みは、こちら（申し込みページへのリンク）をクリックしてください。みなさまのご登録をお待ちしております。

KCPSのプロモーションを担当しておりますヴェムリ ムルティです。
KDDIではKCPS オブジェクトストレージの提供にあたりCleversafe社のストレージ技術を採用しています。KDDIでは、既にこの技術をベースとしてau携帯電話のお客様にau cloud（データお預かり）サービスを提供しており、au のお客様は携帯電話で撮った写真や動画を簡単に保管することが出来ます。Cleversafe社はペタバイト級の大容量データを扱えるストレージソリューションを提供し、高く評価されています。この度、Cleversafe社CEOのJohn Morris氏を迎え、ストレージ業界とIBMからの買収が決定した同社の今後についてお話を伺いました。

IBMによる買収について

Murty:IBMによるCleversafeの買収※についてどうお考えですか？
※米IBMは2015年10月5日（米国時間）、米Cleversafeを買収すると発表しました。

Mr. Morris:当初は独立系のストレージベンダーとして大きく成長し、株式公開を目指していましたが、IBMからは何度かお話を頂き、最後には無視できないオファーを頂きました。もちろん財務的にも魅力的な提案でしたが、それだけではなく、ストレージ業界に貢献するというミッションにおいてとても魅力的だったのです。IBMの一部になるということは、市場へのアクセス、技術補完なども兼ね備えた、財務リソースだけではない新たな投資家を持つようなものです。

Murty: 買収の理由については、理解しました。しかしCleversafeの商品はかなり強いポジションにありました。なぜ買収が必要だったのですか？

Mr. Morris:確かに我々の商品はオンプレミスのソリューションとして強いポジションにあり、IBMと一緒になってもそれは続きます。ただ、IBMはオブジェクトストレージを自社クラウドに重要なコンポーネントと考えているのです。もちろん、IBMは引き続きオンプレミスのソリューションとしてKDDIのような顧客にも提供しますけどね。

Murty:モリスさんにとっては古巣に戻る様な気持ちですよね。以前もIBMで重要なポジションをご経験されたようですが、今後もこのストレージビジネスの運用に関わっていくのですか？

Mr. Morris:そうですね、確かに古巣に戻る気持ちです。IBMでは23年間働きましたから。今後もこのビジネスに携わりますよ。現在の組織はそのままで、私はIBMでストレージビジネスの責任者、シニア・バイス・プレジデントであるロバートマクブランクにレポートすることになります。IBMでは現在のCEOを含めてたくさんの人を知っています。自身で成長させた会社を率いた状態で、以前から知っている会社に戻れるので、私にとっては嬉しい話です。

Murty:あれだけ大きな組織に合流するのですから、心配する事もあるのではないでしょうか？

Mr. Morris:IBMは100年以上の歴史のある企業ですが、7割の買収活動はこの10年に行っています。彼らは外部の考えの価値や小さい組織がイノベーションの源なのは良く分かっていますし、その価値を最大限に引き出すには小さい組織の独自性を守る必要性があるのも分かっています。過去には買収した組織をすぐに統合していましたが、今は買収した組織に統合の時期を任せていますし、またIBMとCleversafeの企業文化は似ています。我々は350以上の特許を持っていますし、IBMは世界で最も特許を持っている会社です。そして、両社とも顧客満足を最重要と考えています。だから考え方が合うんですよ。

Cleversafe について

Murty: 少しCleversafeについてお聞かせ下さい。Cleversafeの商品・技術の特徴はなんでしょうか？

Mr. Morris:現在のストレージシステムはまだまだ従来のレガシーデータに対応している事が多く、これらのシステムが頻繁に更新されるようなデータの対応に特化しています。それに対して、我が社のオブジェクトストレージ技術はネット上で作られるデータに最も適しています。この様なデータはあまり更新されないのです。我々の最大の差別化要素は、急激に増加するユーザーデータに対応したストレージの概念を作り出した事です。この様なデータが増え続ける限り、我々も成長を続けると思います。

Murty:Erasure Codingはかなり前からある技術、概念ですね。それを御社の商品・技術にどの様に採用されたのか教えて下さい。

Mr. Morris:そうですね。Erasure Codingはかなり前からあります。IBMはこの技術をハードディスクのプラッターにデータを書き込む際に使いました。我が社のイノベーションは、この技術を用いてセキュリティと信頼性を保ちながら地理的な分散を可能にするストレージシステムを可能にした事にあります。それがCleversafe創業者である Chris Gladwinのイノベーションでした。彼は以前音楽シェアリングサービスを提供しており、Erasure Codingでもっと効率的なストレージができることに気が付いたのです。

Murty:オブジェクトストレージの利点はどんなところですか？将来的にデータ容量が巨大化した際にこの様なストレージシステムの運用は複雑になると思いますか？

Mr. Morris:それは導入されたシステムによります。オブジェクトストレージにも様々な形態がありますが、我々のErasure Codingを使ったやり方ですとデータの運用はとてもシンプルです。例えば、平均的な一人のシステム管理者が運用するデータの容量は300TBくらいなのですが、Cleversafeのストレージを使うと、運用出来るデータは5PBくらいになるんですね。我々のシステムは非常に効率的なので、あるお客様では３名の技術者で130PBのデータを運用しているケースもあります。コスト削減だけでなく、人的リソースをもっと重要なところに投入することが出来ますね。ストレージは運用がシンプルでなければなりません。

Murty:御社のマーケットシェアやストレージ市場の状況について教えて下さい。

Mr. Morris:我々の規模はストレージ市場全体ではまだ小さいですが、オブジェクトストレージの市場ではリーダーです。今後、ストレージ市場において、オブジェクトストレージは急速に伸びるでしょう。現に容量ベースでは毎年6割のペースで伸びていますし。Cleversafeとしてのチャレンジは、イノベーションを続け、機能を拡充し、能力を向上してリーダーのポジションを維持することだと考えています。我々はすでにEMCやNetAppの様な大企業より先へ行っていると思います。今後も我々がイノベーションを続け、機能や能力を拡大すれば、市場の拡大に伴ってリーダーシップを保持できると思います。我々は毎年売り上げを倍増しており、第3四半期も良い決算発表ができました。

オブジェクトストレージについて

Murty:オブジェクトストレージは今後DBやリアルタイムシステムのような従来型システムに採用されると思いますか？

Mr. Morris:私は今後市場がこの様に変わって行くと考えています。現在ストレージは用途別で５種類程あると思っていますが、将来的にはこれらは２種類に淘汰されるでしょう。一つは非常にハイパフォーマンスが要求されるDBや本番システム、オンラインシステムのようなSSDやDRAMで構築したシステムで、それらはストレージ全体からみると小さな割合になると思います。それ以外のストレージはオブジェクトストレージが占めるでしょう。我々のビジョンはデータがCIFS、 NFS、 S3そしてSwiftといったあらゆるプロトコルで書かれ、どのプロトコルでも読めるようなエンタープライズストレージのハブになる事なんです。

Murty:データ容量はまだまだ増えますね。どの様なアプリケーションがこのデータを消費するのでしょうか？

Mr. Morris:私は、これからも人々がたくさんの写真、ビデオ、音楽等のパーソナルコンテツを生み出し、自分自身や自分の子供、家族の人生を記録して行くことがデータ消費の大きなドライバーになると考えています。auのお客様もどんどん人生記録を au cloud上に載せて行くでしょうし、我々も一緒に成長しながらそれをサポート出来ている事を大変嬉しく思っています。エンタープライス市場でも、企業のビデオや音声、画像データの使用が拡大していますが、これもオブジェクトストレージの拡大と我々の成長ドライバーになるでしょう。

KDDIとの協業について

Murty:KDDIとの協業についてどう思われますか？今後の成長をどう考えていますか？

Mr. Morris：KDDIとの協業は最初から楽しかったですよ。大企業でありながら小さなスタートアップ企業みたいに動きが早い。あらゆる決断が早く、印象的でした。今後の成長については、すでに au cloudでモバイルのお客様向けにサービス提供出来ている事を嬉しく思いますし、KCPSオブジェクトストレージのサービスで参画ができ、KDDIの重要な法人のお客様に貢献出来ることを光栄に思います。KDDIが提供するこのサービスが日本のクラウド市場の成長への起爆剤になればと思います。今後もKDDIと共に成長して行ければいいですね。

KDDIはストレージが企業ITの重要な要素であり続けると考えています。企業はデータを収集し、そのデータを活用することが 競争優位の源泉であることに気づいています。また、サーバ リソースやストレージが安価になっていますので、企業ではビッグデータやIoTなどを生かして顧客の理解を深め、さらに価値あるサービスを安価で提供出来るようになるでしょう。KDDIではお客様に我々の通信サービスと共にクラウドサービスを提供して行きたいと考えています。

今回のインタビューの英文を下記に掲載します。

Cleversafe’s Object Storage-Technology behind KCPS storage-

I am Vemri Murty, in charge of marketing and promotion of KCPS at KDDI.
KDDI has released the KDDI Object Storage (KOS) on September, 2015.KDDI decided to deploy Cleversafe’s storage technology for KOS.  KDDI has already been using this technology as the platform for its cloud storage offering “au cloud” for its mobile phone subscribers.  KDDI’s mobile phone subscribers are able to enjoy a reliable service for storing/backing up their pictures and videos they take on their mobile phones.
We recently met with the CEO of Cleversafe Mr. John Morris and talked about the world of storage and about Cleversafe’s future after acquisition by IBM. Below are the excerpts from our discussion.

Acquisition by IBM

Murty: Are you excited about the acquisition* by IBM?
*IBM announced the acquisition of Cleversafe on the 5th of October 2015

Mr. Morris:Of course. Initially, we wanted to grow into a large, standalone storage company and eventually go public. But IBM spoke with us a few times and eventually made a very compelling offer. It was compelling financially to the investors, of course, but it was also compelling for us as it would help us fulfil our mission of making a difference in the world of storage. Being a part of IBM is like having a new investor with not only deep financial resources, but also resources like market access and technology, which can help us achieve our mission.

Murty: We understand the logic behind the acquisition, but your product is already pretty strong. Why did you think you needed the help?

Mr. Morris: Our product is strong as an on premise solution and that will continue with IBM. IBM views object storage as a very critical piece of their own cloud offering.  So, they want to continue to offer it as an on premise solution to customers like KDDI (KCPS) and also offer it as a part of their cloud service.

Murty: So, its like going back home for you ! You have worked at various senior roles at IBM. You would continue to oversee the operations.

Mr. Morris: Yes, it’s like going home. I worked for 23 years at IBM. I will continue to oversee Cleversafe’s operations. The present organization will stay intact and I will report to Robert LeBlanc, senior vice president of IBM Cloud. I know the people at IBM, including the CEO, so it will be a very easy transition. It will be very exciting as I will be part of a company I know and will still lead a company I have helped build.

Murty: How do you feel about integrating into a much larger organization? Are you concerned?

Mr. Morris: IBM is a 100-year-old company, but 70 percent of its acquisitions have happened in the last 10 years. So, they see the value of thinking from the outside and they understand that the sources of innovation are smaller companies. They understand that in order to capitalize on the advantages, such as innovation, they have to protect the uniqueness of the smaller company. In the past, the integration would have happened very quickly, but now they let each company decide how fast that should happen. Also, I believe the IBM and Cleversafe cultures are closely aligned. We have about 350 patents and IBM has the most patents worldwide. Both companies also believe that customer service is paramount, so we certainly have shared views.

About Cleversafe

Murty: Let’s talk a bit about the product itself. What is the unique part of your product/technology?

Mr. Morris: Most of the storage systems sold today are still designed to handle legacy data.  They are optimized for systems where the data changes frequently. Object storage, on the other hand, is optimal for data which is generated on the web. This kind of data typically doesn’t change. The biggest differentiation is that we have created a storage approach designed for data requirements that are driving the industry today. And as long as this kind of data grows, we will continue to grow.

Murty: Erasure coding has been around for a long time now. Tell us a bit about how you have implemented that in your product/system

Mr. Morris: Yes, erasure coding has been around for a long time. IBM previously used it to ensure data was written to the physical platter in a hard disk. Cleversafe is innovative because we use erasure coding to enable geographical dispersion of a storage system while providing security, reliability and efficiency. This innovative use of erasure coding was the invention of Cleversafe Founder Chris Gladwin, who previously ran a music sharing service and found that erasure coding made storage more efficient.

Murty: What is the advantage of object storage? Do you think in the future it might get difficult to manage such a system as the data gets bigger?

Mr. Morris: It depends on what kind of system is deployed. Object storage is available in various forms. Cleversafe’s unique approach and design with erasure coding makes it very simple to manage and operate the system.  The average storage administrator manages about 300 terabytes of data, but a typical administrator on a Cleversafe system can manage about 5 petabytes of data. Our system is very efficient. One of our customers has 130 petabytes and they are managing that data with only 3 people.  This not only helps in cutting costs, but companies are also able to redeploy resources in other more competitive areas. Storage should be easy to manage.

Murty: Can you share your thoughts on Cleversafe’s market share, your thoughts on the market, competition.

Mr. Morris: While we are small in the storage market, we are the leaders in the object storage market, and the object storage portion of the overall storage market will grow very fast. Presently, it’s growing at about 60 percent per year on capacity basis. Cleversafe’s challenge is to maintain its leadership and continue innovating, extending the features and capabilities of the system.  We are already ahead of larger companies like EMC and NetApp. If we keep innovating and expanding our capabilities, we will be able to maintain the leadership position as the market grows. We have been doubling our revenue every year and have announced very good results in the third quarter.  

About object storage

Murty: Do you see object storage getting into the area of traditional storage systems real time systems or databases where object based storage is not considered presently.

Mr. Morris: This is how I think the market will evolve. Right now, enterprises use about five tiers of storage systems, depending on the requirements. Going forward, I think that will merge into two tiers. First would be the very high performance tier, which would be a small portion of the overall storage capacity and would consist of flash memory, SSD or even DRAM based systems. These would service the world of databases, production systems, online transaction processing systems. The remaining portion of the storage capacity will be addressed by object storage. Our vision is an enterprise storage hub where data could be written by any protocol like CIFS, NFS, S3 or Swift, and can be read by any of those protocols.

Murty: We know data volumes are going to grow much more. What do you think will be the few applications that will consume storage going forward?

Mr. Morris: I think people are going to generate a lot of personal content, such as music and photos/videos documenting their lives and their children, and that is going to be a massive driver. We are very happy to be supporting au cloud where au subscribers are going to put more and more of their lives on to their cell phones, which will drive growth for us. In the enterprises, they are also using more video, audio and scanned images, and those will be big drivers for Cleversafe’s growth and for object storage in general.

About working with KDDI

Murty: How do you think about the relationship with KDDI. What do you think about the future growth?

Mr. Morris: It was very pleasant working with KDDI. Despite being a large company, KDDI moved fast like a small start-up company – decisions were made very quickly and it was very impressive. As for future growth, we are thrilled to be part of the au cloud service for consumers and we are honored to be introduced to KDDI’s very important enterprise customers as part of KCPS. I hope this can be a catalyst for the growth of the cloud market in Japan and for the growth of KDDI, as we know that means Cleversafe will grow in the process.

We believe that storage will continue to be an important aspect of enterprise IT systems. This is more so because of business are aware that how they use the data they collect can give them huge competitive advantage. Also, since compute is becoming cheaper (as is storage), enterprises will be able to leverage concepts like Big Data, IoT to better understand their customers and provide better and more customised services to at reasonable prices.We at KDDI are excited to about the opportunity to help our customers with our cloud services along with our telecommunications services.

はじめまして。DevOps実践を担当している運用本部の廣田です。2015年4月から、KDDIクラウドプラットフォームサービス(以下、KCPS)のパートナーサービスとして、株式会社はてなのサーバ監視サービス「Mackerel(マカレル)」を提供しています。Mackerelを導入することにより、サーバのリソースやサービスの稼働状況を直観的なUIとグラフ化によって把握することで、システムの稼働トレンドの把握やサービス品質向上に役立ちます。今回は、インフラストラクチャ自動化フレームワークである「Chef」を利用して、より簡単にKCPSにMackerelを導入する方法を紹介します。Chefを利用することで、サーバ上で複雑なコマンド実行を複数回繰り返すことなく、Cookbookと呼ばれるプログラムコードを一度実行するだけで、Mackerelを導入できます。サーバの台数が増えても、Cookbookを適用すれば導入にかかる時間と手間を大幅に削減できます。

Mackerelのカスタムメトリック登録について　

Chefを利用してKCPSにMackerelを導入する手順を説明する前に、Mackerelの「カスタムメトリック」機能について紹介します。Mackerel全体の特徴は、過去の記事KCPSから「Mackerel」提供開始！ 〜Mackerelで実践するサービス利用状況の”見える化”〜をご覧いただきたいと思います。KCPSでは、Webサーバやデータベースやファイルサーバなど様々なミドルウェアを導入し、ご利用いただいておりますが、カスタムメトリック機能を使うことで、様々なミドルウェアのメトリックを収集できますので、システムの状況を詳細に把握することができます。Mackerelをひとたび、導入すると、自動で以下のシステムメトリックがグラフ化されます。

・ロードアベレージ(直近5分間計測) ※Linuxのみ
・CPUプロセッサの待ち行列内のスレッド数 ※Windowsのみ
・CPU使用率
・メモリ使用率
・ディスク使用率
・ディスク IOPS (Read/Write)
・ネットワークインタフェースの送受信パケット数

これらは、「システムメトリック」の項目に表示されます。カスタムメトリックは上記以外に、グラフ化したいメトリックを収集するスクリプトをMackerelに登録することで、グラフ化でき、「カスタムメトリック」の項目に表示されます。例えば、Windows ServerのWebサーバ機能であるIISの接続数をメトリックとして、Mackerelに登録するPowerShellスクリプトは、以下のようになります。

$Server = $env:COMPUTERNAME
$SiteName = "default web site"
$Perf = Get-Counter -Counter "\\${Server}\Web Service($SiteName)\Current Connections"
$PValue = $Perf.CounterSamples.CookedValue
$TimeStamp = $Perf.TimeStamp
$EpochTime = Get-Date $TimeStamp -uFormat "%s"
Write-Output web_service.current_connections`t$PValue`t$EpochTime

実行すると以下のように結果が出力されます。

web_service.current_connections   8   1451317190.60106

ファイル名を「WebServiceConnections.ps1」として、「C:\mackerel-scripts\」に保存します。Mackerelにカスタムメトリックを登録するスクリプトは、標準出力を以下のフォーマットで出力する必要があります。

{メトリック名}\t{メトリック値}\t{エポック秒}

登録後のメトリック名とメトリック値とUNIXエポック秒をタブ(\t)区切りで出力します。次にMackerelエージェントの設定ファイルに、以下の設定を追加します。

[plugin.metrics.webserviceconnections]
command = "powershell C:/mackerel-scripts/WebServiceConnections.ps1"
type = “metric”

「command」の部分で、さきほど紹介したIISの接続数メトリックを取得するPowerShellスクリプトを指定します。
Mackerelエージェントの設定ファイルに、Mackerel APIキーを指定するのも忘れずに行います。

apikey = “(Mackerel管理コンソールからコピーしたAPIキー)”

Mackerel APIキーの確認方法は、過去の記事KCPSから「Mackerel」提供開始！ 〜Mackerelで実践するサービス利用状況の”見える化”〜にて紹介しています。Mackerelに設定を反映するため、Mackerelエージェントを再起動すると以下のようにIISの接続数をグラフ化できます。

Mackerelを自動導入するChefのCookbookを作成する

Chefとは、サーバやアプリケーションといったインフラストラクチャの展開を容易にするためのオープンソースの自動化フレームワークです。専門的知識を持ったエンジニアが、サーバにコマンドを実行して構築を行っている作業を、Chefで自動化し、いつでも誰でも、サーバ構築することが可能になります。KCPS上でのChef Server構築と機能検証も実施しておりますので、ご興味がありましたら過去の記事Chef Server12をKCPS上に構築、活用方法を検証をご覧ください。今回は、このChefを利用して、KCPSのWindowsサーバにMackerelを導入し、システムメトリックと前章で紹介したIISの接続数のカスタムメトリックをMackerelに登録する方法を紹介します。Chefを利用するには、サーバにChef Development Kit(以下、ChefDK)の導入が必要になります。Windows版のChefDKは、Chef社からこちらにて配布されています。Chefでは、インフラストラクチャに対する導入や設定をRubyの文法で記述された「Cookbook」に定義します。このCookbookを構成する要素のうち「Recipe」、「File」、「Template」について、説明します。

■ Recipe
Recipeは、Cookbookの中心的役割を果たします。インフラストラクチャ構築を実施するプログラムコードです。今回、使用する、MackerelエージェントをインストールするRecipeは以下になります。

windows_package ‘mackerel-agent’ do
  source "http://198.18.0.16/file/msi/mackerel-agent-latest-kcps.msi"
  installer_type :msi
  options "APIKEY=\" (Mackerel管理コンソールからコピーしたAPIキー)\""
  action :install
  not_if {::File.exists?(‘C:/Program Files (x86)/Mackerel/mackerel-agent/mackerel-agent.conf’)}
end

template 'C:/Program Files (x86)/Mackerel/mackerel-agent/mackerel-agent.conf' do
  source 'mackerel-agent.conf.erb'
  owner 'Administrator'
  group 'Administrator'
  mode '0644'
end

directory ‘C:/mackerel-scripts’ do
  owner 'Administrator'
  group 'Administrator'
  mode '0755'
  action :create
end

cookbook_file ‘C:/mackerel-scripts/WebServiceConnections.ps1’ do
  source ‘WebServiceConnections.ps1’
  owner 'Administrator'
  group 'Administrator'
  mode '0755'
end

service 'mackerel-agent' do
  service_name "mackerel-agent"
  action [:restart]
end

Chefには、プログラムのインストールであったり、ファイルの配置であったりとサーバ構築を行う様々な機能があり、これをリソースと呼びます。Recipeに、リソースを記述し、サーバ構築を行うプログラムコードを作成します。上記のRecipeに記述されたリソースを説明します。

・windows_packageリソース

インストールファイルが置かれるURLとインストーラーのタイプを指定し、インストールオプションにMackerelのAPIキーを指定してMackerelエージェントをインストールします。

・templateリソース
後述する「templates」フォルダにMackerelエージェントの設定ファイルを配置します。templateで、指定するフォルダにMackerelエージェントの設定ファイルをコピーする。

・directoryリソース
フォルダのパスを指定し、カスタムメトリックを収集するスクリプトを格納するフォルダを作成します。

・cookbook_fileリソース
後述する「files」フォルダに前章で紹介したカスタムメトリックを収集するスクリプトの「WebServiceConnections.ps1」を配置します。このスクリプトをsourceとして指定し、directoryリソースで作成したフォルダ配下に格納します。

・serviceリソース
Recipeで実施される内容を反映するため、インストールされたMackerelエージェントサービスを再起動します。

■ File
Cookbook内の「files」フォルダにファイルを同封しておくことで、Recipeに記述する「cookbook_file」リソースを利用して、サーバにそのファイルを転送し任意の場所へ配置することができます。

■ Template
Cookbook内の「templates」フォルダにファイルを同封しておくことで、Recipeに記述する「template」リソースを利用して、サーバにそのファイルを転送し任意の場所へ配置することができます。「Template」は、ファイル内に動的に変化する変数がある場合に使用し、「File」は、変数がない、静的なファイルの場合に使用します。

以上で、Mackerelを導入するCookbookの説明は終わりです。紹介したCookbookが、サーバ上で実行する構築内容をまとめます。

・Mackerelエージェントのインストール
・Mackerelエージェント設定ファイルの配置
・カスタムメトリック取得スクリプトを格納するフォルダの作成
・カスタムメトリック取得スクリプトをフォルダに配置
・Mackerelエージェントサービスの再起動

Cookbookは以下のようなファイル構成になります。

cookbooks/
└── mackerel-kcps-win
    ├── CHANGELOG.md
    ├── README.md
    ├── files
    │   └── default
    │       └── WebServiceConnections.ps1
    ├── metadata.rb
    ├── recipes
    │   └── default.rb
    ├── templates
    　    └── default
    　       └── mackerel-agent.conf.erb

Cookbookのファイル構成を説明します。

・「cookbooks」フォルダ配下に「mackerel-kcps-win」フォルダを配置します
・「Recipe」、「File」、「Template」を「mackerel-kcps-win」フォルダに配置します
・「CHANGELOG.md」には、変更履歴、「README.md」には、Cookbookの説明を記述します
・「metadata.rb」は、Cookbook名や作成者情報などのメタ情報を記述します

KCPSにMackerelをChefで導入する

KCPSに、前章で紹介したChefのCookbookを適用します。このCookbookを適用すると、自動でMackerelエージェントが導入されて、システムメトリックに加え、カスタムメトリックとしてIISの接続数をグラフ化することができます。Cookbookを適用するKCPS上の仮想サーバには、あらかじめ以下の設定を行います。

・OSはWindows Server 2012 R2
・Windows版のChefDKをインストール (こちらのChef社のページから入手)
・Webサーバ (IIS) のインストール

ChefDKをインストールすると「chef-client」コマンドが使用できます。試しにコマンドプロンプトを起動して以下のコマンドを実行してください。

PS > chef-client --version

実行すると以下のようにバージョンが表示されます。

Chef: 12.5.1

Chefには、ChefサーバからCookbookを適用する方法とサーバ無しで適用する方法があります。今回は、サーバ無しの方法で適用します。適用には、「chef-client」コマンドを使用します。「chef-client」コマンドを実行するために以下のファイルを用意します。

・Cookbook
さきほど説明したMackerelエージェントを導入するCookbookのことです。「mackerel-kcps-win」フォルダに「Recipe」、「File」、「Template」などをまとめます。

・client.rb
Cookbookの格納場所やCookbook適用に使用するキャッシュを格納する場所を指定します。

・windows.json
実行するCookbookの名前を指定します。今回は、「mackerel-kcps-win」です。

client.rbに、以下のように記述します。

file_cache_path "C:/chef-repo/cache"

cookbook_path "C:/chef-repo/cookbooks"

log_level :info

また、windows.jsonに以下のように記述します。

{
  "run_list": ["recipe[mackerel-kcps-win]"]
}

「Cookbook」、「client.rb」、「windows.json」をまとめて一つの「chef-repo」フォルダに格納します。「chef-repo」フォルダ内に「client.rb」内に定義したように、「cache」と「cookbooks」フォルダを作成しておきます。「chef-repo」フォルダのファイル構成は以下のようになります。

chef-repo/
├── cache
├── client.rb
├── cookbooks
│   └── mackerel-kcps-win
│       ├── CHANGELOG.md
│       ├── README.md
│       ├── files
│       │   └── default
│       │       └── WebServiceConnections.ps1
│       ├── metadata.rb
│       ├── recipes
│       │   └── default.rb
│       └── templates
│           └── default
│               └── mackerel-agent.conf.erb
└── windows.json

Cookbookを適用する準備が整いました。「chef-repo」フォルダを今回は、C:\の直下に配置し、コマンドプロンプトを起動して、cdコマンドでC:\chef-repoに移動します。

PS > cd C:\chef-repo

以下のコマンドでCookbookを適用します。

PS > chef-client -z -c client.rb -j windows.json

以下のような結果が出力されていれば、Cookbookの適用は成功です。

Chef Client finished, 6/6 resources updated in 23 seconds

以下は、「chef-client」コマンドを実行した動画です。実行後に、「mackerel-agent」がプログラムにインストールされていることが確認できます。

「7 Metrics」の部分を確認すると、システムメトリックに加えて、カスタムメトリックに「web_service」が追加されています。

さいごに

今回はMackerelのカスタムメトリックの登録方法と自動化フレームワークであるChefを利用してKCPSの仮想サーバにMackerelを導入する方法を説明しました。今までエンジニアがコマンドの投入によって行っていたサーバ構築が、Chefを利用すれば、より正確に、より素早く構築することができます。KCPSでは、Chefサーバを準備しています。今回説明したMackerelの導入およびカスタムメトリックの登録を自動化するCookbookを活用した新サービスを検討しておりますので、ご期待ください。