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 メンテナンスなものにしたいのですが、
ここからはいろいろとあると思いますがノウハウとして蓄えればと思います。
実施したことや引っかかった部分はおいおい書いていきますが
今日は絵を描くだけで精一杯なのでここまで汗
PagerDuty始めました 導入から二ヶ月実際のところどうなのPD?【cloudpack 大阪 BLOG】
運営の方が初めての事というのでオブザーバーとして協力させて頂きましたが
と、ご紹介して頂いて涙・・・って感じでしたが、JAWS-UG大阪じゃなくなっていて
オペレーションじょうずになっていました汗。
多分、第二回早くしろって感じのプレッシャーもあると思いますが、第二回ではなく、
ってのを10末にしますので許してくださいw。
で、本編です。
cloudpackでPagerDutyを導入したのが5月で、
６月は業務の傍らがんばって運用可能な状況までセッティングして、
７月から運用を開始し二ヶ月が経過しました。
導入前は
な感じの構成でした。
なお導入はUIでポチポチ設定なんてしていたら全然追いつかないので、
APIを駆使し何百のサービス(インスタンス数では無いです。監視サービス数ですw)を
登録の自動化などして他のメンバーが移行に携わらずに出来る状況を作って
移行は一人でやり抜きましたが、移行後の最初はPagerDutyはアラートメールでの
監視のおまけ的なポジションでAckなども気が向いた時にやるって感じでした(涙)・・・が、多拠点運用・複数人による監視などの不特定な状況化で、必要なタイミングで
通知が来て、メールベースだと誰が対応するかslackで名乗りをあげていたのが
ポチッとクリックするだけで、モレや重複して作業をしなくても良いと気づくと
一気にPD最高って話になりました。
よくslackとの連携でアラートをslack上に投げるってのも見ますが、
通知の垂れ流しなので正直使い物になりません。
複雑なcloudpackのMSPのシフトスケジュールもgoogle apps spreadに
記載したものをgoogle apps scriptとPDのAPIで流し込めるようにして
複雑なシフトの入力問題は解決させました。
【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] - 雑なA型によるクラウドとモバイルと運営と
環境によっては、監視サーバーにpagerdutyのpluginを入れれない場合や、
メール通知のアドレスの分も修正できないケースの監視サーバーなどもありますが、
そこはメールからgoogle apps scriptでPagerDutyにAPIでインシデントを登録するような対応もしています。
急なシフト変更やサービスのメンテナンスモードの設定も数クリックで設定でき、
非常に便利です。
で、現在はインシデント管理だけではなく
google apps scriptなども駆使して、
backlogの担当者未が設定された通知
EC2•RDS•ダイレクトコネクトのメンテナンス通知
などもMSPの当番の人にエスカレーションされるようになっています。
※赤色の線の部分はリストラ予定ですw。hubotやDBはLambdaとDynamo DBに変更して
※ フルマネージドな環境にします(hubot飽きたw)。
google apps scriptもたまに謎のエラーが出ますが、これもPagerDutyで管理しており、
google apps scriptのエラーの場合、ここを見てねってのがPagerDutyのDescriptionに
記載しているので、googleの謎のアラートもどんと来いですw
とりあえず2ヶ月間が立ちましたが、MSPの運用負荷の削減にもなったので(運用も
一部見直したのもありますが、PDが無ければ出来なかった)
PagerDutyのcloudpackのMSPへの導入は当たりだったと思います。
皆様も是非活用して、TIPSのアウトプットしてください〜
PagerDuty始めました。インシデントの可視化を行うPagerDutyのレポート機能【cloudpack 大阪 BLOG】
cloudpack大阪のメンバーのBLOGが続々と公開されました。
元開発メンバー3名・インフラエンジニアからの異色のチームですが
元開発メンバーはどんどんインフラ力を吸収し(cloudpackでの時間は
通常の三倍以上と言われています)、日々成長していますw
※本音は元開発メンバーでも全員技術&リーダーも出来るので、
※短期的な事を考えると、開発で月30人月ぐらい回すほうがありかなと思ったりもしますw
で、今回はPgaerDutyのReoprts機能です。
PgaerDutyのReoprts機能ですが、導入初期に関してはうーんあまり使わないなーって感じで考えていました・・・が
こんな画面で、System/Team/User/Alerts/Incidentsタブで観点(画面)を変更し、
Report by:でService/Escalation Policyを選択(cloudpackのMSPな使い方だと
Service)、
Day/Week/Month/期間設定で表示範囲を指定、
ViewでNumber of Incidents/Mean Time to Acknowledge/Median Time to Acknowledge/90th Percentile Time to Acknowledge/Mean Time to Resolve/Median Time to Resolve/90th Percentile Time to Resolveを指定します。
ざっくりとインシデントの総数やMTTA(Acknowledge(着手)するまでの平均時間)やMTTR(Resolve(解決)するまでの平均時間)などを見て、
各監視対象に対しての客観的な判断が可能となります。
また詳細に関してはIncidents TABを選択し、
日ごとのリストが出ますのでView Onlineや自動化ならDownload CSVでファイルで
日単位で発生したインシデントを確認する事が可能です。
View Onlineで日単位の情報を取得し、DurationやEscalated?の値を見て、各インシデントが、cloudpackのサービスとして問題なかったかの確認を行います。
今までは感覚的な部分(問題になったものだけがクローズアップされがちで、
日常のパフォーマンスなどが見えにくかった)が多かったですが、
PagerDutyを導入する事により、インシデント管理を定量的に確認し、
インシデントの多いサービスをピックアップする材料を
PagerDutyで作成する事が可能になったので、この情報を巧く活用していきたいと思います。
