1.
40歳のおっさんが開発のプロマネから
クラウド最前線の
インフラエンジニアになってみて
2015.11/3
⽐比企 宏之 @unioce
JAWS FESTA 2015

2.
⾃自⼰己紹介
☁ Cloudpack⼤大阪 MSP開発 セクションリーダー
ソリューションアーキテクト
– 構築・24/365運⽤用
– MSP運⽤用⾃自動化推進役
☁ バックグラウンド
– 携帯電話/スマートフォン端末開発
エンタープライズシステム開発を経て
2014.4より現職
– AWS SAMURAI 2014
– JAWS-‐‑‒UG MVP 2013
– Innovation EGG代表
– TwilioJP-‐‑‒UG 全国アドバイザー
– さくらクラブ アドバイザー

3.
⾃自分の経歴
☁ 氷河期⼀一期⽣生 半年年間仕事なしで公園のベンチを暖める汗
☁ ２年年間ほど某通信会社で運⽤用する→つまらないし開発にいきたい
☁ 12年年ほど開発の会社で10年年近く携帯電話のプロジェクトに携わり、
PMとして負け知らず⾚赤字知らず。
☁ 4年年間ほど⽂文教とセキュリティソフトの⽇日本⼀一の会社で受託開発を
⾏行行い記録は継続→
クラウドがしたかったけどクラウドは早いと⾔言われ仕事としては
指を加えてるだけで、コミュニティ活動としてcloudを⾏行行う。
インフラの仕事経歴全くなし

4.
20代前半は７次請で150万をお客様からい
ただいて、⾃自分の会社には50万以下・・・
しかも開発経歴三ヶ⽉月で1次受けのリーダー
をする・・・
会議でまわりは40代で⾃自分だけ20代前半
とりあえず態度度だけでかくしてみる

5.
アウトソーシング開発の課題
☁ どんなに仕事に成功しても、仕事が取れない時は⼲干上がる。
☁ エンジニアは仕事のない間コスト扱い。
☁ 気がついたらエンジニアは経営や営業をすべきと、経営側や営業側
が責任を押し付ける。
でも経営や営業は技術がわからないと平気でいう。
☁ 受託をしながらいつか新サービスをとリスクのない素晴らしい話を
しているが覚悟もないから何も⽣生まれない。
買わない宝くじ状態で時間だけが進む。
☁ 新サービスとストックビジネスを夢⾒見見ながら
ずっと受託開発をして時間が過ぎていく。

6.
2007年年リーマンショック・・・
地⽅方の多くのエンジニアが
もっとも消耗した事件

7.
2009年年
Google App Engineとの出会い
エンジニアの福⾳音

8.
2011年年から
コミュニティ運営をやってみた

9.
⽀支部⻑⾧長として⽴立立ち上げしてました
五年年間 1172名https://jawsugosaka.doorkeeper.jp

10.
こんなのやってます
⼆二年年間 734名https://innovationegg.doorkeeper.jp

11.
こんなのやってます
https://innovationegg.doorkeeper.jp

12.
こんなのやりだしました
6⽉月開始で333名https://jawsugosaka.doorkeeper.jp

13.
そんなのをしていたら
AWS⼆二代⽬目エバからつけられた
字名(あざな)はJAWS-‐‑‒UG 軍師 汗

14.
コミュニティの⽴立立ち上げ

15.
2015年年7⽉月15⽇日
これからどうするかを
三⼈人で飲んで打ち合わせ

16.
19時30分•••
技術的な話で盛り上がる・・・
21時•••
Amazon API Gatewayの話で盛り上がる
宋さんがAmazon API Gateway UGを
⽴立立ち上げようって話になる・・・

17.
22時•••
TwilioJP-‐‑‒UG⼤大阪の話が全く出てこない
新原さんが突っ込みを⼊入れて
ようやく本題

18.
これぐらいゆるいんですw

19.
cloudpackとの出会い
☁ 技術的な話を確認されたことが実はない・・・
☁ コミュニティ活動を⾒見見て声がけされた(講師としてはほとんど出て
いない(守秘義務のせい))
☁ でも他のクラウド関連の会社からも技術の話をされずに声がけされ
てたw
☁ コミュニティ運営おそるべき
※ゴルフ以上に⼈人が⾒見見えるのがコミュニティ

20.
24時間365⽇日
有⼈人監視運⽤用保守

21.
cloudpackの技術系セクション説明及び連携
☁ 設計・構築運⽤用セクション
→設計など⻑⾧長期スケジュールの構築
＊エンタメ系、エンプラ系など複数セクションに分かれている
☁ MSPセクション
→24/365の運⽤用や短納期系の構築を担当
☁ 開発セクション
→アプリ・API開発などを伴う案件を中⼼心に担当
☁ 社内インフラ・Security＆NWセクション
→顧客対応はDirectConnectやDeepSecurityを担当

22.
cloudpackの技術系セクション説明及び連携
☁ 原則運⽤用はMSPにて⾏行行う
→他セクションは運⽤用に乗せるまで
☁ 各セクションは引継ぎ資料料をMSPに提出
→Backlogのwikiを活⽤用
☁ 引継ぎ資料料に無い対応はエスカレーショ
ン
→お客様への⼀一次連絡はMSPにて⾏行行う

23.
MSPセクションの役割
☁ 定例例業務
→定期動作チェック、定期監視チェック、レポート作成など
☁ アラート監視
→お客様連絡、⼀一次対応（障害切切り分け）など
☁ 環境構築
→短納期（キャンペーン系など）の構築
☁ 通常依頼対応
→ユーザ追加、設定変更更など
☁ 運⽤用設計
→既に構築済で運⽤用からcloudpackに依頼する場合の設計及び環境整備
cloudpackではアラート（障害）対応は24/365で⾏行行っているが依頼対応は原
則営業時間帯の受付となっている

24.
MSPセクションの役割
☁ シフト
通常シフト ：10:00 – 19:00
早シフト ：8:00 – 17:00
遅シフト ：14:00 – 23:00
夜間シフト ：23:00 – 8:00
＊⼟土⽇日祝⽇日は通常シフトは無し

25.
MSP運⽤用とSOC2対応
SOC2ってご存知ですか？
→受託業務に係る内部統制の保証報告書（SOC報告書：
Reporting on Controls at a Service Organization）の事
を⾔言います。 cloudpackがお客様へサービスを提供する際
に、このサービスを提供するcloudpackの内部統制のデザ
インや運⽤用状況について、監査法⼈人や公認会計⼠士が独⽴立立し
た第三者の⽴立立場から客観的に検証した結果を記載したもの
です。報告書では、⼀一定の基準やガイダンスに基づく合理理
的な保証（絶対的ではないものの、相当程度度に⾼高いレベル
での意⾒見見）が表明されます。
参考：
http://blog.cloudpack.jp/2015/07/15/what-‐‑‒is-‐‑‒soc2-‐‑‒
type1-‐‑‒report-‐‑‒for-‐‑‒cloudpack/

26.
MSP運⽤用とSOC2対応
なぜcloudpackでSOC2運⽤用を⾏行行うのか
☁ クラウドってセキュリティは⼤大丈夫なの？
→クラウド⾃自体のセキュリティはAWSなどクラウドベンダーが
担保してくれます
☁ クラウド運⽤用のセキュリティは⼤大丈夫なの？
→ここは⾃自分たちで担保する必要があります。セキュリ
ティのみでなく品質などのサービスレベルも第三者に検証
して貰う事でお客様の安⼼心を頂く事を狙いとしています。

27.
MSP運⽤用とSOC2対応
MSP運⽤用する場合のSOC2対応は主に下記の
⼆二つとなります。
☁ 障害対応
☁ システム変更更対応
→全てにおいてお客様・作業者・管理理者にて証跡を残
しています。

28.
MSP運⽤用とSOC2対応
☁ SOC2では必ず承認が必要となります
→品質はあがりますが、スピード的には遅くなります
☁ SOC2では必ず作業をトレースできるよう
にログを残す必要があります
→莫⼤大なログの保管と調査可能な仕組みが必要となります
という事で⼈人的にもサーバリソース的にも
多⼤大なコストがかかります。

29.
MSP運⽤用とSOC2対応
下記の仕組みにより⼈人的コストは減らしています
☁ AWSコンソール作業
→個⼈人単位IAMアカウントにてコンソールにログインし
CloudTrailを使⽤用してログをS3に保存
☁ サーバ作業
→個⼈人単位OSアカウントにて踏み台サーバにログインし作
業ログを⾃自動でS3に保存
各ログインはLDAP認証で⾏行行い、ログインの
前にBacklogの課題番号を登録が必須

30.
9⽉月まででMSP運⽤用で使っているツール

31.
MSP運⽤用で使っているツール

32.
http://unioce.hatenadiary.jp で⽇日本語で情報展開中

33.
インシデント管理理システム
NagiosやSENSU・Zabixなどのアラートを
集約。
アラート対応の漏漏れをなくすために、
担当者単位で操作。
担当者のスケジュールを作成し、スケ
ジュールにそった通知が可能。

34.
APIやWebhooksを利利⽤用すると他のプログラ
ムやサービスとの連携が可能。
⽐比企はslackに情報を垂れ流流してslack万歳と
いう⼈人ではないのでPagerDutyの上記連携
フル活⽤用(後で)。

35.
実際にどのように運⽤用しているのか
作業依頼・障害対応をwikiに掲載されてい
る内容に従って、顧客連絡及び対応を⾏行行っ
ています。
以上

36.
実際にどのように運⽤用しているのか
そんな簡単にいくわけありませ
ん！
cloudpackでは
数百の案件、数千のサーバ（インスタンス）を運
⽤用していたりします
お客様の要望には（基本的には）全て応えます！
まさにクラウドコンピューティングだからできる
事です

37.
実際にどのように運⽤用しているのか
☁ 運⽤用
○設計・構築運⽤用がwikiに案件情報を記載
■顧客情報、システム構成、障害対応⼿手順
→全ての情報を記載するのは難しい
○運⽤用中の顧客要望の変更更
■運⽤用レベルの⾒見見直しはMSPにて対応
→MSPにて顧客調整も実施
■顧客要望によるシステム変更更
→既存影響などあるため、設計・構築運⽤用にエスカレー
ション

38.
実際にどのように運⽤用しているのか
システム設計に関する考え⽅方もMSPと設計構築で違います。
例例）DBに関する設計
・MSPの希望
→冗⻑⾧長化・バックアップなどがマネージドされているRDSを
使ってほしい
・設計構築の希望
処理理速度度や短時間フェイルオーバーを考えてEC2上にMySQLを
構築してデータはエフェメラルディスクを使⽤用してMHAによる
冗⻑⾧長化
当然お客様ありきの話です。cloudpackでは性能のみでなく運
⽤用負荷や障害復復旧、データ消失のリスクを各セクションの意⾒見見
をもって提案しています。

39.
実際にどのように運⽤用しているのか
☁ アラート対応
○アラート連絡レベル
■アラート全部
■サービス影響あった場合のみ
■⼀一次対応の⼿手順渡すので、まずは対応してほしい
○連絡⽅方法
■メールで連絡してほしい
・Backlogへの連絡によるメールで問題ない
・緊急連絡⽤用のメーリングリストに連絡してほしい
■電話してほしい
・出なかったら留留守電で問題無い
・複数⼈人に順番で出るまで連絡してほしい
広範囲に影響が出ている障害時にシフト当番では厳しい場合もある。

40.
実際にどのように運⽤用しているのか
☁ 脆弱性対応
○連絡までは⼀一⻫斉通知で可能
■個別に作業タイミングの調整
→場合によっては夜間帯や休⽇日の対応
■お客様の環境による前提の違い
→個別に調査・⼿手順書の作成
お客様の規模により100台以上の規模のシステムもあれば
1台でLAMP構成などもあり。
→単純に構成管理理ツール（ChefやAnsibleなど）で対応で
きない

41.
実際にどのように運⽤用しているのか
運⽤用・アラート対応・脆弱性対応など多数のパターンがあ
るためMSPのみでは厳しい場合が多々あります。
セクション関係無く（⼈人海戦術で）対応します。
営業時間外→担当に電話及びslackで全体通知
そうするとこんな感じでフォローが⼊入ります。

42.
実際にどのように運⽤用しているのか
システム化できる部分はシステム化し、標準化できる部分
は標準化します。（アラート検知の仕組み、定例例作業簡易易
化など）
ただ、結局は
⼈人の⼒力力に頼らざるを得ません
・・・ですが

43.
やればできる内容もある
・最初のフェイズから
⼊入って⾃自動化
・既存の案件の⼀一部⾃自動化

44.
9⽉月までのMSPシステム

45.
運⽤用スケジュール管理理システム

46.
運⽤用スケジュール管理理システム
時間が来たら
Slackに投稿される&
Pagerdutyにインシデント登録され
状態を管理
作業が着手されなければ、
slackに再度通知
作業が着手されたらslackに投稿(PDもクローズ)

47.
MSPのシステムをEC2タイプから
Non EC2にしてみて

48.
MSPのシステムをEC2タイプから
Non EC2にしてみて

49.
MSPのシステムをEC2タイプから
Non EC2にしてみて

50.
10⽉月以降降MSP運⽤用で使っているツール

51.
10⽉月以降降MSP運⽤用で使っているツール

52.
10⽉月からのMSPシステム
Lambda＆API GATEWAY&
Dynamo DBへ変更更

53.
次期MSPシステム
Twilio & SORACOM AIRで挑戦

54.
次期MSPシステム
Non EC2をコンセプトに
SaaS・PaaSを徹底活⽤用

55.
コンテナ技術を
現在最もうまく使っているのがLambda
・疎結合
・エンジニアが好きな⾔言語を選ぶ
エンジニアファースト
MSP運⽤用で徹底的に対応し
案件で活⽤用する流流れを作る

56.
MSPのシステムをEC2タイプから
Non EC2にしてみて
完全に冗⻑⾧長化・フルマネージド
しかも
97%OFFのコストダウンが可能に!
※AWSさん、Lambda進めて⼤大丈夫？

57.
これからのcloudpack
・社内(MSP開発) MSPツール基盤構築
※上記を進めるにあたり、検証も含めLambdaに
置き換えたMSPの現⾏行行システムを
10⽉月20⽇日にリリースし、その知⾒見見を元にMSP開発にフィードバッグする。
MSPの24365にとって必要と思われる内容
①障害発⽣生時の電話のログ取り（MSPサーティフィケートで
指摘あり・TwilioとSORACOM AIRでの対応検討中）
②Backlog（課題数・コメント数）とPagerduty（インシデント数）
を元にどのセクションが案件に対してどれだけ対応したかの
⽬目安を出せるようにする
③運⽤用コストを下げるためにアラートの数を減らす努⼒力力を
担当者に伝える仕組み

58.
⼀一年年ほどインフラエンジニアを
やってみた感想
☁ 技術は慣れてくる(えげつないのでは
ない限り)
☁ そもそもクラウドが始まって数年年だから
格差もまだ他のやつに⽐比べれば現時点で
はマシ。
☁ 保守がストックビジネスなので仕事が
⼊入ってこなくて⼲干上がる⼼心配が少ない

59.
これからクラウドに参⼊入するエンジニアへ
☁ 時間が遅れれば遅れるほどクラウドエン
ジニアとできる格差が広がる
☁ 経歴よりもチャレンジ精神。
新サービスがどんどん出てくるので
それを楽しめる気持ち。

60.
これからクラウドに参⼊入するエンジニアへ
☁ 単純な開発のビジネスの会社では⼲干上が
る。ちゃんとビジネスになる会社に⼊入る
べき。
☁ インフラエンジニアにチャンスがあるが
開発エンジニアにもチャンスが
いっぱいある。

61.
1年年間24365の運⽤用をしたからこそ
意味のある⾃自動化をしたい。

62.
cloupack ⼤大阪と東京では
開発者を絶賛募集中
もちろんインフラエンジニアも

63.
Cloudの最前線でワクワクしませんか？

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

65.
cloudpack WANTS YOU