24365の運用を支える仕組み。PagerDutyを活用する為に【cloudpack大阪BLOG】
最初は自分一人で運用をどう自動化するか？を観点にPgaerDutyの導入から
作業スケジュールのリマインド機能付きslack通知・とあるMSP顧客の各種要望などを
構築/運用業務の傍らにやっていましたが、MSP開発もメンバーが揃いだし、
本格的な開発が可能になってきました。
ただ開発者のエゴな車輪の再発明や、
ターゲットが定まってない状態での自動化などの暴挙は行わず
まず運用の可視化や確実性を高めるサービスの導入をひとまず行っています。
※他の現場の可視化が気になって下記勉強会を開催します。よかったら是非
cloudpackの運用ではslackをメインにコミュニケーションを行っていますが、
slackの通知はすぐに流れる為に24365で確実に担当者に情報を伝える仕組みとして
PagerDutyをインシデント管理以外も含め活用しています。
非常に便利なPagerDutyですがPagerDuty自体の設定を担当者がミスしていたり、PagerDutyがSLA100%を保証していないのでPagerDutyが正常に稼動しているのか？を監視する必要があります。
その方法として、cloudpackではPagerDutyのサービス障害が発生を想定してアラートメールも併用して冗長化していますが、MSP開発ではアラートメールの内容とPagerDutyの状況を突合させて設定漏れやPagerDutyが正常に動作しているか？を SESの受信とLambdaを利用してチェックし、PagerDutyが正しく動作しているのかを別の観点からチェックする事を可能にしました。
MSPはcloudpackのビジネスの根幹です。
お客様に24365のサービスを提供する為にSaaSのサービスを活用するのは必然ですが
利用しているSaaSのサービスが正常に動いていませんでしたって言い訳はお客様にはできないので、MSP開発では日々様々な改善を模索し、開発を行い作成した機能の運用も行っていき、MSPのクオリティを高めていければと思います。
※1 除外設定PD登録のLambdaはアラートメールはあるけどPDに登録されてないものを
PDに登録するLambdaです。
このLambdaで登録されたインシデントはPDに登録された瞬間に自動でクローズされ、突合する時の情報の為だけにPDに登録されます。
この機能により、PDのインシデント登録情報=アラートメールの状態となり、
PDのインシデント登録情報≠アラートメールの場合は漏れとして扱われます。
IoTはバズワードか？を確かめたくて開催したInnovation Egg 第六回
去年の9月ごろ「IoTはバズワードか？」と色々と思う事がありました。
僕の「IoT」が電子工作の域を出なかった理由 - ニートの言葉
なBLOGの投稿がバズっていましたが、自分の経歴である
オープンシステム系開発→制御系開発→モバイル端末開発→
と移ってきたときに制御系開発/モバイル端末開発が
シリアルケーブルやLAN・3Gなどに接続されている環境で育った中で
ラズパイにセンサー繋いでクラウドにつなげてクラウド側で様子を見る電子工作の延長に、何ら目新しさを感じず、日本の製品開発のシビアをさを経験した自分からしてみたら、本当に工作レベルの話でした。
なのでIoTをビジネスとして捉える場合、シスコが提唱しシスコの八子さんが
わかりやすく語ってくれるIoEに関しては初めて聴いたときに、
ああこれなら理解できるって感じで、比企のIoTはIoEでした。
そして関西のIT業界やデバイスメーカーの方にもIoEを知って欲しいなと思い
八子さんに打診し、
を開催する運びになりました。
9月から数ヶ月たち少し状況は変わり、あれIoTってバズワードでは
無くなってきているなと感覚的に感じる事が身近で多くなり、
9末のSORACOMさんのサービス開始などの発表を受け、IoTの繋げる環境が
容易に手に入る状況になってきました(まだまだLTEのモデムなどは
高い状況にありますが、LTEのIoTやMtoM向けの通信規格だと
非常に安価になるようなので更にどうゆう敷居が低くなります)。
そして年初めにはメーカーの多い関西の特性を生かして
IoTの新しいイノベーションが生まれるかわかりませんが、
IoTというキーワードで人や企業が繋がって新しい関係性が作れればと思い
Facebookに「関西オープンIoTグループ」
https://www.facebook.com/groups/447677528759870/
というグループを、関西のハッカソンの盛り上がりを作り出している
元公務員で今は企業された角さんやハンズオン系の勉強会や
生徒にもITを教えている吉田さんと上記グループを作成しました。
※非公開ですが、参加資格はIoTに興味のあって前向きに語り合える良識のある方が
参加資格です(関西じゃない人も入れますw)。ひねくれたものの見方をして
問題点だけ語って建設的な発言をされない自己満足な方は参加できません。
そして開催二日前のSORACOMさんの
で、C・D・E・Fの各サービスをストリーミング配信で見たときに
更にIoTが身近になったというか、IoTの範囲を超えてIoTを
包み込むようなSORACOMさんのサービスを発表を聴いて
更に色々と考えるようになりました。
※発表時にさくらのIoTも実はSORACOMですって電撃発表を受けた時に
SORACOMの片山さんとさくらインターネットの小笠原さんが同時に
登壇する場所を関西で作れたのは非常に胸熱でしたw
そして開催当日です。
開催の様子はTwitterで #IEGG で検索していただければ少し様子が
伝わるかと思いますが、
八子 知礼さんの「 IoTで日本から世界に再挑戦！ 」
※以降の方の写真は https://www.facebook.com/InnovationEgg/ でw
SORACOM-UGから株式会社ソラコムの片山 暁雄 さんの
大阪Innovation egg 第6回資料：SORACOM AirやBeamそして新サービスについて
Twiliojp-ugのcloudpack大阪(iret株式会社)の高橋 慎一さんの
関西おうちハック/GCPUGの株式会社バスキュールの松本 雅博さんの
自作デバイスをmyThingsにつなごうインフラからみたDevOps勉強会の株式会社IDCフロンティアの大屋 誠さんの
ハンズラボ株式会社の田部井 一成さんの
ハンズラボの考えるIoT Innovation EGG 第6回 『IoT 今と未来』
新規AWS開発系ユーザーグループAWSceanからcloudpack大阪(iret株式会社)の青池 利昭さんの
JAWS-UG 関西 IoT専門支部 の 株式会社KYOSOの辻 一郎さんの
[JAWS-UG関西IoT専門支部] IoTで関西のコミュニティをつなぐ
Node-REDユーザー会で日本アイ･ビー･エム株式会社の北瀬 公彦さんの
GCPUGでGoogle Incの佐藤 一憲さんの
Having fun with Google Cloud + RasPi // Speaker Deck
さくらクラブでさくらインターネット株式会社の小笠原 治さんの
「さくらがIoTってなにやんの？ 」
と怒涛のセッション内容でした(innovation EGGの状況は他の方がBLOGに書いていただけると期待)。
特にGoogleの佐藤さんのデモはただ繋げるではなく、googleのサービスと連携させて
デバイス単体では不可能な内容を見せて頂き、会場からこういうのもあるのか？
と驚きが出ていました。
懇親会も盛況で、今までInnovation EGGに来たことがない方も参加しており、
関西以外からも名古屋・東京・四国と遠路はるばる来ていただいていました。
懇親会の席も非常に盛り上がったのですが、懇親会の席でデバイスメーカーの方が
「IoTを自分たちがするかを選択できる時代ではない。IoTな世界になった時にどう自分たちの市場を守っていくのか？」と、言われていて、
自身が日本の携帯電話開発をしていて、日本携帯が全盛期のころにiPhoneが現れて、
未完成なAndroidがgoogleから発表され自身もAndorid端末の最初のほうに開発をしていた時に、「Androidはいずれ日本の携帯電話市場で日本メーカーの優位性をなくしてしまう。これからはクラウドの時代だからクラウドに移行する」と決断した時に
逆らえないIoTの波の中でどうデバイスメーカーが戦っていくのか？というのに対し
近親感を覚えました。
IoTは参加する立場によって様々な入り方があり、WEBの開発者がラズパイを触って始めるのと、デバイス側の方がクラウドによっていくのは全然別のアプローチ・感覚になりますが、WEB側の人とデバイスメーカーの人が入り方は違えど同じエリアに入って
色々と議論し、たとえIoTでなくても新しいinnovationやビジネスが生まれれば Innovation Eggや関西オープンIoTグループは運営する価値はあるのかなと、
この頃自分自身はIoTの定義をあまり考えなくなってきたわけです。
Innovation Eggは秋頃にもう一度IoT関連の事をしようかと思っていますが、
デバイスメーカーの人や、まだクラウドに触れていない人のために
開発者向けAWSユーザーグループのAWScean(直近では2月27日にTwiliojp-ugと同時開催)
で、AWS縛りになりますが(範囲を広げると大変だと思うので)、
デバイスメーカーの方含めた非クラウド系の方向けに開催しようかなと思っています。
最後に
2000年前半あれほど売れていた日本のモバイルメーカーは
数年で現在の状況になりました。
端末のスペックでは世界一と言われた時もありましたが、携帯電話としては
当時未完成だったAndorid端末にどんどんと侵食されていきました。
日本のセンサーは世界的に精度が高いと言われていますが、
クラウド側とつながったそこそこの精度のデバイスが、現在の状況を
ひっくり返す事は無いとは言えません。
IoTはバスワードかどうか？なんて議論は評論家に任せておいて、
自分達のIoTはどうなのか？を自分自身で考えていただければと思います。
4桁の方が参加してくれたコミュニティを運営してみて
長らくやっていたJAWS-UG大阪の支部長を退任しました。
今後JAWS-UG大阪はJAWS-UG全国で議論されている？、コアメンバー制度に
結果的にシフトします。
そんなのでちょっとJAWS-UG大阪の今までを少しまとめてみたいと思います。
自分がコミュニティという存在を意識し出したのは2009年頃のリーマンショック後でした。
関西や地方の景気はひどく落ち込み、自分が所属していたアウトソーシングのIT開発業界も、リストラや個人事業主が廃業したりと非常にひどい状況でした。
仕事がなくなれば今までドル箱だったエンジニアはコストとして扱われ、
非常にひどい状況でした。
比企自身も自分や自分の部下の仕事を確保するために色々と頑張りましたが、
リストラや仕事を取れても競合会社の社員のほうがリストラされるという、
勝者なき泥沼な状況でした。
そんな時にAndroidの会にたまたま参加して、そこで企業の垣根を越えた世界が
展開されており、そこには子会社や下請けなどの多重構造の仕組みはなく、
参加者自体がフラットな状況でした。
このような世界にエンジニアの全てが参加したら、まだいくらかのエンジニアは
職を失った時にでも救われるのではないのだろうか？と考え、
自分の部下とかにコミュニティに参加するように促し、口だけ言ってもついてこないので、自分も一緒に参加するようにしました。
その頃ちょうどクラウドの技術が見える範囲にあらわれて、これはエンジニアに対しての福音であると思ったのと自分が携わるモバイル業界はAndroidによって日本メーカーのアドバンテージがなくなると思ったので、あえてクラウドを自分でも進めて行こうと思いました。
ただコミュニティに自身が運営しようなんて気持ちはこれっぽっちもなかったのですが
に参加して小島さんや玉川さんの話を聴いて、Google App EnginやAzuruのPaaS派だった比企がIaaSがメインのAWSに興味を持つようになりました。
詳しくは？
に記載しています。
そして
Japan AWS User Group (JAWS) - Osaka勉強会 第1回 : ATND
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第2回 : ATND
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第3回 : ATND
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第4回 : ATND
と開催していきましたが、実は運営としてはあまりうまくいってませんでした。
で色々あり、自分と去年亡くなられた益子さんが
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第5回 : ATND
からメインで運営を行うことになりました。
益子さんも自分と同じ業界でかつ以前は競合会社のリーダー同士で同じ時代を
生き抜いてきた同志で、クラウドとコミュニティの可能性を理解して、面倒な内容も
行動してくれる人でした。
そしてJAWS-UG大阪は少し他のJAWS-UGの支部とは毛色の違う感じになりました。
オープンなコミュニティでいろんな人が参加するようにしたいと思ったので、
かなり告知したり存在感をアピールしたので、他のコミュニティからも
浮いた存在として扱われていましたが、そこはあえて見て見ぬふりをしました。
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第６回 ６/２(土) : ATND
は参加者も増え、AWS芸人の清水さんもLTに参加したりして、講師の地産地消も
考え出したのはこの時期ぐらいからでもあります。
そして大型イベントである三都物語2013の開始を控えた、
Japan AWS User Group (JAWS-UG) - Osaka勉強会 第7回 12/15(土) : ATND
は、年末の忘年会シーズンにやってしまい、マズイこのままで大型イベントしたら
やばいなと思っていた時期でもありました。
そしてそんな中JAWS-UG初の大型イベント
を仕切って、JAWS-UG神戸の小賀さんやJAWS-UG京都の染田さんや
運営メンバーとともに乗り切って、無事成功することになりました。
現コアメンバーの金春さんや桶谷さんが運営に参加する事になったのも三都物語がきっかけです。
三都物語は非常に多くのメンバーで実施しましたが、少人数の運営で
マルチトラックをしたらどうなるんだろう？と試してみたのが
でした。
この頃から運営コストの省力化を考えるようになってきました。
※かなり自身でも負担になってきましたが、
負担になっていろことを人に任せるのもなと思い、やり続けました。
JAWS-UG Osaka 第9回勉強会 Beginners&ServiceProviders 11月2日(土)｜
をしたあたりに、本当にしんどくなり、
なれていたイベントレジストから、イベント単位ではなくコミュニティとして
参加者を集める(過去に参加したメンバーにも簡単にアプローチできる)、
に移行しました。
また関西の各支部のJAWS-UGの登録サイトの統合も進めました。
※告知を多くすると、どうしても周りから別の反響も返ってきて辛い部分もありました。
どうしたら人が集まるのか？ってのは自分担当だったので、色々と試し、
増えるのと維持のノウハウを貯めることが出来たのが、今では自分の宝です。
そして
は、他のコミュニティとの調整を実施した経験が、その後の
Innovation EGG <IT系コミュニティ合同•未経験者向け勉強会> | Doorkeeper
の運営のノウハウにつながるようになりました。
ただ、大型イベントに対して、本当に必要なのだろうかというのも
少しずつ考えるようにな出しました。
特に大型イベントの公式サイトに関しては、DoorkeeperとFacebook pageとかで
シンプルにしたほうがよくない？って感じもあり、
また他の地方の運営の方を巻き込むと他の地方のJAWS-UGの活動が
おろそかになって、地方を盛り上げたいのに
ちょっと違うなって違和感も出てもきました(ここはお祭りを一緒に楽しみたいって
地方の方もいますので、あくまで比企の所感です)
過去の参加者に容易にアプローチできるDoorkeeprの効果は素晴らしく、
またAWSやJAWS-UGの勢い？も出てきて、運営での告知のコストなどもあまりいらなくなってきて、昔はTV大阪さんが好意で貸してくれた場所以外で場所を借りる事は難しかったのですが、今では大阪イノベーションハブさんやエムオーテックスさん・そしてMBSさんなど、たくさんの場所を提供していただける行政や企業がでてきて、
内容さえしっかりしていれば、カジュアルに開催できる基盤と流れが出来たかなと思い、
今回の
は、AWSの新サービスの勢いもありますが、告知から短い期間で
100名以上の方がエントリーするような状況にもなりましたので、
当初目的である
・人が集まるコミュニティ
はJAWS-UG大阪としてはそれなりに出来たかなと思ったので、
支部長を継ぐ人も前から言ってましたが、うまく譲れなかったので、
全国で議論されていたコアメンバー制度に乗る形で退任する事に決めました。
今後のJAWS-UG大阪がどのようになるかはまだわかりませんが、
たまに自分がやりたいJAWSUGの勉強会があればその時だけ運営するみたいな
形で、通常の運営にはノータッチとなりますので(古参がいるとやりにくいと思うので)、クレーム等は比企には言わないでくださいw。
コミュニティをこの4年間ほど運営してみて、結果的に色々な人に巡り会い、
新しい人間関係が生まれ、インフラの経験もないのに、cloudpackに参画して、
忙しいながらもクラウドの最前線を楽しみ充実した毎日を過ごせるようになりました。
自分がコミュニティに接する前はオープンソースも嫌い(ソフトが無料という考えが
理解できなかった)でボランティア活動である
コミュニティ運営なんて自分の今までの行き方の中でまったく考えれないものでしたが
今ではやってなければどんな事になっていたのだろう？って感じです。
自分だけではなくコミュニティの中からも、色々な出会いやビジネスが生まれ、
やってよかったな〜と思います。
今後は
Innovation EGG <IT系コミュニティ合同•未経験者向け勉強会> | Doorkeeper
の主催や
の大阪コアメンバー兼全国のアドバイザーや
のアドバイザーなんかをやっていって、違ったコミュニティの形で
クラウドの普及やIT業界の人が交流・流動的にいきていけるコミュニティを
運営していきたいと思います。
とりあえず近々の自分の活動としては、
や
と、innovation Egg一色ですが、関西のクラウドやIoTがもっともっと盛り上がって
たくさんのIT業界の方に、力になる技術の紹介と交流が生まれる場所を提供できればと思っています。
最後にJAWS-UG大阪や関西のイベントに参加していただいた方ありがとうございました。
またJAWS-UGの運営に協力してくれたスタッフや講師の方ありがとうございました。
引き続き新しくなるJAWS-UG大阪をよろしくお願いします。
さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その1)【cloudpack 大阪 BLOG】
前回から19日の日が経ちましたがBLOGを書くのをサボっていたのではなく
忙しかったのもありますが
ようやくこのタイトルのシステムが3日間エージングして
ある程度目処が立ってきたのでようやくBLOGを進めます。
※けっしてRe:InventのLambda祭りに乗っかろうと思ったわけではないです・・・汗
fluctの使い方は
を見ていただければと思います。
どちらも細かい設定は手動で行う必要があるので、
今回は先に試していたfluctを使います(大きな違いは今の所ローカルで動作させるときの違いが
fluctはローカルのサーバーを起動させて、curlなどでアクセスするのに対して
jawsはコマンド一発でlambdaの部分をコールするのですが、JAWSのほうが
putやgetのパラメータの渡し方が見当たらなくソース見ているほど暇もないので
確認していません)。
で、今回は実現するシーケンスを記載したいと思いますが、
その前に今回のリプレイスでどれぐらい金額が変わるのかを説明します(1ドル120円換算で今回は720時間で換算)。
もともとのシステムはEC2のマイクロインスタンス１台の上にいろいろ載せていて
冗長化されてませんが、本来は冗長化する必要があるので大きくお金のかかる部分では
・EC2(t2.micro 1時間 0.02ドル)✖️2=3,456
・RDS(t2.micro・MYSQL・MAZ 1時間 0.052ドル)✖️1=4,492
=7,948円の金額がかかります(データの転送量とかもありますが移行後のシステムも
かかるので除外)
移行後のシステムですがLambdaは無料枠がずっとあり、その範囲で収まる内容ですのでLambdaはお金がかからず、dynamodbがテーブル2つと読み込みのキャパがTOTALで10・書き込みのキャパがTOTALで6で済むので512円(容量代と通信料金は別ですが
そんなに大した額ではないのでここは算出外)と93%OFFなシステムとなります。
※今回のシステムは必ず動く必要があるが負荷はあまりないという特性もあります。
で、シーケンス図です(この図の番号を元に次回以降説明できたらと思います)。
google apps script(以降gas)のタイマーを起点にgoogleカレンダーの情報を取得。
実施しないといけないスケジュールがあれば、gasからAPI Gateway経由でLambdaを
呼び出して、Pagerdutyにスケジュール情報をインシデントとして登録します。
PagerDutyはwebhooksで再度API Gatwayを呼び出してLambdaで
slackにも通知します(Pagerdutyは全てのユーザーがアカウントを持っていないですし
周知の意味も込めて投稿します。前システムがslackのUIがメインだったので
互換性を保つことも考慮してのことです)
上記シーケンスではslackに表示されたAPI GatewayのURLをクリックすると、
API Gateway経由でLambdaでPagerdutyのAPIをコールして、
Pagerdutyのwebhooksから、API Gateway経由でLambdaでslackに作業を着手したことを伝えれます。
なんかえらく回りくどいなと思うかもしれませんが、
なケースや
なケースにおいてもほぼ同じシーケンスと同じAPI GatewayのAPIで実現する事が可能となり、結果的に処理がシンプルになります。
またこの処理をする事によりAPI Gatewayを二つ用意してAPI Gatewayの冗長化もする(
意味はあるのか？w)なんかもできたりします。
Pagerdutyの役割は、スケージュールをインシデントとして確実に管理するのと
Lambdaが昨日まではできなかった、着手されてない作業のリマインド(Cron)の処理を
エスカレーション機能とwebhooksの機能を使う事により実現させる事でした。
ただエージングしていたらLambdaにCronの機能が追加されたって
いかにもクラウドな世界のスピード感ですね汗。
でもこの次にやる事が、LambdaのCronだけではできないのと、タイマー処理は
基本的に自分の中ではイベントドリブンとしてはいけてないと思っているので
別に良いかなと。
シーケンス図は上記のような感じです。
ちなみにこの形になったもう一つの理由がPagerdutyのWEB Hooksの動作にあります・・・
PagerdutyのWeb Hooksは1つづつのインシデントが登録された場合は、
1インシデント 1webhooksなのですが、
タイミングが重なると
・2(A・B)インシデント 1webhooks(A・Bが一つのwebhooksで届く)や
・2(A・B)インシデント 1webhooks(A・Bが一つのwebhooksで届く) + 1webhooks(Bのみ)
・2(A・B)インシデント 1webhooks(A・B) + 1webhooks(A・B)
など、必ず情報は飛んでくるけど、重複する可能性もあるという
どぎつい挙動があります汗。
上記のような挙動を制御をシンプルなAPIで制御したい思惑もあり上記のようなシーケンスになりました。
とりあえず今日はここまで
技術的な部分に関しては次回以降で説明したいところですが、
Soracom Airを使ったシステムの作成と検証や、
や
の登壇や、
の主催など仕事も忙しいのにいろいろやっていて、趣味のガンプラも進捗止まっている状況なのでなかなか更新されないかもしれません汗。
少しずつでも解説できればと思いますのでよろしくお願いします。
さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その0)【cloudpack 大阪 BLOG】
JAWS-UGの京都が10/21(水)に実施されるようです。
大阪オフィスのメンバーも登壇や運営に参加するようなので
実施時は暖かく見守ってあげてください。
話題は変わり、cloudpackのMSPのIT化で使っているMSPのシステムですが
日時業務や運用スケジュールの通知＆リマインダー機能(ここ重要)や
月次業務の一部自動化などを支えていてメンバーも方からも日常的に使っていただいてもらっており、面倒を見ている私以外のMSPの方々は安定運用しているな〜って
感じで見えていると思います。しかし・・・
な構成で動いていたら良いのですが、最初は予算もなく効果も見えなさそう＆
そもそもそんなにシステム的に負荷はかからないということで
な構成で作っていましたが、あるべき姿にそろそろすべきかなと思いましたが
負荷もそんなにないのに最低の性能のインスタンスで冗長化してもコストは高くなるのと、Hubot使っているのですが、Hubotの機能をほとんど使ってないのと(
文字入力なんていちいちしてれない)、
slackがhubotのリンクを勝手に切る事件が過去数度あり、方針として
して
にしちゃおうと、時間のないなか、休日や帰ってからも含め、
この一週間ほど頑張ってましたが、とりあえずエージングまでは
できそうだったのでBLOG書きました。
フルマネージドなサービスの活用、対障害性を冗長構成のもの以上にするを
モットーにNo メンテナンスなものにしたいのですが、
ここからはいろいろとあると思いますがノウハウとして蓄えればと思います。
実施したことや引っかかった部分はおいおい書いていきますが
今日は絵を描くだけで精一杯なのでここまで汗
