シンジです。そもそもクラウド屋とは一体なんなのか。10月14日金曜日に、年次のユーザー向けイベント「cloudpack LIVE」を開催。IT系記事で有名なアスキーの、クラウド界隈で有名な記者である大谷イビサさんが参加されたということで、イビサさんの書いた記事を読みながら紐解いてみます。
ソースはこちら
ASCII.jp：開発からデザイン、運用までクラウド利用を支えるcloudpack (1/2)
http://ascii.jp/elem/000/001/251/1251248/
アイレット株式会社とは何屋なのか
cloudpackとは、アイレット株式会社の商品のことを指しますので、社内にはcloudpack事業部というものがあります。元々アイレットはクラウドと言われるものが存在しない時代にWeb系のアプリ開発屋さんとして立ち上がりましたので、その事業は今でも継続されています。今年で創立14年目です。
それらの開発をメインに行っているチームは、結果的にこういう話題が出ます。
「ところでこのアプリ、どんなサーバー使う予定ですか？」
サーバーの調達は常に課題になります。もちろん、運用も課題です。開発チームはcloudpackチームと連携を取ることで、AWSだけでなく、AzureやGCP、ニフティやIIJやさくらインターネット、もちろんオンプレミス含む全てのインフラを対象に、顧客にとって最も費用対効果に優れた提案をワンストップで行う事が可能となっているわけです。事実上ほとんどがAWSですけどね。AzureやGCPとのハイブリッドにすることもあります。
開発するのはWebサイトだけではありません。Webアプリはもちろん、それらのデザイン（UI/UX）、各種ゲーム（課金アイテムやバランス調整、計画的アップデート含むそれらの計画と実行）や、必要とあれば負荷試験、脆弱性試験、そしてcloudpackによるデプロイから運用まで、これらの全てがワンストップです。
社員数が増え続けている
まだまだオンプレミス最強な分野もあるのは事実ですが、クラウドの利用を前提に検討を始めるのが一般的になりました。見る人によっては「なんだクラウドってこんなことしか出来ないのか」とも言えますし、「クラウドを使えばこんなことができるなんて知らなかった」なんて人もいるでしょう。時代はクラウドとか言われてますけど、後者の方が多いからそうなるわけです。
クラウドできるやつがスゴいのか？
優秀なプログラマーは人気者なのか？
アイレットCEOの齋藤将平が常々口酸っぱく言ってる事があります。
「コミュニケーションまじ大事だから」
ということで、東京は虎ノ門ヒルズに加えて港区の田町にオフィスで2拠点、大阪グランフロントに1拠点、近々では名古屋にもオフィスを開設します。シンジが入社したのは2013年、現在2016年で153名の社員数となりました。記事には約3倍と書いてありましたが、入社当初はもっと少なかったように思います。まだまだ拡大予定です。
アイレットの採用基準の大前提と言われているのが、技術力や実績ではなく、コミュニケーション能力です。シンジも役員陣と一緒に面接をしてきましたが、技術的な話しはほとんどしませんし、テストもありません。シンジもAWSを全く触ったことがないところから始まりましたが、未だにあんまり触りませんさーせん。ゴミカスゲームニートのシンジを採用したアイレットのチャレンジ精神に感謝していますさーせん。
ここ1年のcloudpack
デザイン専門部隊
デザイン専門部隊が出来たのは大きな変化かもしれません。自社Webやチラシはもちろんのこと、クラウドネイティブアプリを作る場合のデザイン視点が秀逸ですし、シンジも個人的に助けられた部分がたくさんありまして、ドコモさんが主体で提供しているAWSの利用費用を可視化するツール「Cost Visualizer」のUI/UX大改造に、大きく貢献してくれました。
未だにはっきりと覚えています。
ドコモさんのオフィスにて
シンジ「Cost Visualizerの見た目ってなんか、アレじゃないすか、アレなｗｗｗ」
ドコモさん「アレっすよねーｗｗｗ」
シンジ「なんかウチにデザイン部隊いるので作っちゃいますかｗｗｗ」
ドコモさん「まじすかいいっすねーｗｗｗ」
シンジ「んじゃやりまーすｗｗｗ」
そんなこんなで完成です。実際シンジは何もしてませんさーせん
認証・認定
プライバシーマークをはじめとする各種認証は、なんやかんやでいろいろ増えて、いまこんなかんじです。
- プライバシーマーク 継続監査
- ISO:20000 ITSMS 継続監査
- ISO:27001 ISMS 継続監査
- ISO:27017 クラウドセキュリティ(NEW)
- PCIDSS レベル1 継続監査
- SOC2 セキュリティ及び可用性 年次更新
- AWS独自監査 年次更新
AWSからの監査によって、「Big Dataコンピテンシー」や「Migration Managed Service Partnerコンピテンシー」など、なんかいろいろ持ってるっぽいのですが、もはやどの監査がなんの監査なのかよく覚えていません嘘です。
今年のSOC2監査は、Type2での監査になるので、まさにいまやってるところです。3ヶ月間監査ですからねー。長いわー。
AWS請求代行サービス
これが謎システムなのですが、cloudpackのAWS請求代行サービスを使うと、AWSと直接契約するよりも、3%割引価格になるうえに、毎月約150万円以上もかかるAWSエンタープライズサポートを利用出来る上に、日本円での支払いができるというシステムになりました。これリリースしてから様々なお客様からよく質問を頂くのですが、
「ぜったい裏あるでしょ、なんか使えないとかさ」
そうなんですよ。ないんですよ。むしろ、AWSのアカウントがcloudpackの管理下に入るということは、先述した各種セキュリティ認証を運用しているうえで取り扱われるということで、顧客数が増えれば増えるほどシンジが大変になるというだけなんですね。
あんまり書くと多方面から怒られると分かってて書きますが、請求を代行しているだけのサービスですから、お客様のAWS環境にとやかくあれこれ言うことは絶対にありません。ですが、セキュリティ事故がそのアカウントで発生すると、cloudpackの24時間365日体制のエンジニア達が、本来はやらなくてもいい契約形態なのにもかかわらず、お客様に状況をお知らせしたり、アドバイスしたりすることもまーまーあります。ってか速攻で連絡してます。
この辺はまだプレスリリース打つほどの内容までは煮詰まってないのですが、ただAWSの費用請求を代行してもらっているという、それ以上の付加価値をガンガンに付けていくつもりです。こーゆーのはシンジくん得意なんです。
ホワイトペーパーという形でノウハウを公開
シンジが書いたセキュリティホワイトペーパーを皮切りに、社内の取り組みやノウハウを、ホワイトペーパーという形の読み物にして提供することにしています。社内で何か課題を解決すると、すーぐCTOの鈴木が
「これホワイトペーパーにしようぜｗｗｗ」
っていうようになってから早1年。現在は5種類のホワイトペーパーを公開しています。
cloudpackホワイトペーパー｜AWS専業のcloudpack
https://cloudpack.jp/whitepaper/
知識の共有ってとても難しいことですよね。ホワイトペーパーは、その役割を担ってくれている気がしています。社内研修でも使いますし、営業が資料として使うこともあります。そろそろシンジ担当のホワイトペーパーもアップデートしようと思いながら早半年、社内革命が起きすぎていて書くタイミングを逃しています。といういいわけ。
約6700台のサーバーを監視
って記事には書いてありましたけど、データベースとかサーバーレスとかいろいろアホほどあるので、実際はこんな規模感じゃないだろと思いつつも、それはさておき24時間365日運用を実現しているMSPチームはcloudpackの柱と言っても過言ではありません。サーバー管理には様々なツールを使っていますが、
- adminpack（AWSアカウント管理）
- Pagerduty（アラート管理）
- Datadog（サーバーモニタリング）
- Backlog（課題管理）
だけではなくて、お客様によっては、ウチはSykpeがいいとか、Chatworkがいいとか、Redmineがいいとか、そりゃもういろいろありますよ。山ほどあるんです。これを、cloudpackは上記4つを使っているので、これでお願いしますとは言わずに、お客様に合わせるんですね。そんな統制が取れていないようにみえるMSPチームが何故か統制が取れているという謎システム。
MSP部隊は徹底的に人間が隣りに貼り付いて教育するのですが、この教育の資源となっているのは「お客様」です。記事中ではバンダイナムコエンターテインメントさんの事例を紹介していますが、ゲームのイベント時にはアクセスが集中するよ！だとか、障害が起きたときの連絡フローは大丈夫？だとか、今となっては当たり前だと思えることの多くは、お客様からの声を頂いたお陰で洗練されているというわけです。
MSP部隊を統括している新谷さんは常々言っています。
まずはお客さんありきだから。
このマインドを社内に広め続けるのがシンジの使命でもあるなーとも思っています。
SRE部隊の活躍
Service Reliability Engineerの略称で、最近はやってるらしーです。社内では別名、イベント対応チームとも呼ばれます。MSP部隊とは別なんですね。何が違うのかというと、SRE部隊が担当しているプロジェクトを見るとなんとなく見えてきます。
- Jリーグ
- NHK紅白歌合戦
- バーチャル高校野球
下の2つは分かりやすいですよね。とある日程、とある時間帯だけ、アホほどアクセスされるWebサイトをAWSで運用するわけです。その瞬間のためだけに構築して、終わったらさようなら。でも、アクセス過多で落としたら負け。Jリーグの場合はもっと複雑で、人気のあるチーム同士の戦いだったらWebも戦争になるし、天気にも左右される。AWSだったらELBとかALB使って負荷分散できるじゃんとか、いろいろ想像できますよね。実際に運用すると、それでは間に合わないんです。数秒間でも落としちゃいけないだけじゃなくて、重いと感じさせたら負けなんです。だからといって価格の高いサーバーを事前に並べまくっておけばいいってもんじゃないですよね。とんでもない金額になっちゃいます。だから人間が予測して、徹底的に自動化して、実際の放送なんかを見たりしながらバーストトラフィックを人間の手で捌いていくわけです。
その一瞬、アクセスが集中する、それをなんとかしたい
SRE部隊は絶対に落とさないWebシステムを。最小限のコストで提供します。
そんなこんなでイビサさんありがとうございます
いいことばかり書きましたが、お叱りを受けることもあります。まだまだ不十分なことだらけです。明日もしょーへー社長と2時間サシでミーティングですよ。社内で起きた問題、お客様にご迷惑をおかけしてしまった問題、ご要望などが、全て漏れなく経営陣に届くようになっていて、「ちゃんとやれ」ではなくて、「会社として組織としてどうしたらいいだろうか」というのを毎日議論しています。
シンジはとあるお客様から飲みの席ではあるものの、「アイレットのここがダメだ会をやったほうがいいよ」と言われて、確かにそりゃそうだなと思ったそのときから実行しています。
来年の今頃はどうなってるのやら、全く分かりません。
なんかすごいことになってそうな気はしています。
と、来年のイベントへのハードルを上げましたので、不満や疑問があるかたは、担当のエンジニアか担当の営業か、もはやしょーへー社長に直接ご連絡下さい。シンジはメールを見ない宗教を信仰しているため、しばらく山にこもります。
