雑なA型によるクラウドとモバイルと運営と

大阪でInnovation EGGを運営している人のBLOGです。時々更新します〜

「LINE API Expert」の初代メンバーの一人に認定されました!

「LINE API Expert」の初代メンバーの一人に認定されました!

 

 

なぜ比企がLINEにたどり着いたのか?は別の機会として、

なぜLINEを選んだのかってのは、
開発者は大きくわけて4つのやりたくないがあり、

その理由の一つをクリアするPFなので、推しています。

やりたくない作業として
<ドキュメントを書く・インフラの面倒を見たくない・テストしたくない・アプリの審査したくない>
その中での比企のアプローチは「インフラの面倒を見たくない」は

サーバーレスで”ある程度”ですが前進していますが、

「アプリの審査したくない」は、
審査特有の作法やちょっとでも内容が担当者に理解されなければ
すぐにリジェクトされるという、アプリの審査の為の作業や設計が無駄に必要です。


LINEのchat botは、その審査のお作法的な作業的な部分が存在せず(

もちろんエロ関係はダメですが)に、
POCのレベルでもガンガン試すことができ、

この時代にあったスマフォアプリのリリーススタイルをとることができると思っています。

またサーバーレスアーキテクチャーでアプリをサクッと作りたい時にも、LINEのchat botのPFは有効に働き、
サーバーレスアーキテクチャーでの実装にも適した存在です。

もちろんアプリを作るのにも有効で、これはもう少ししたら、

実践の場で見せたいと思います!

LINE API Expertとして、LINEのPFの普及ももちろんしますが、
サーバーレス&LINE PFで、エンジニア(特に地方)がもっと面白い事の実現の為に、
認知の活動を実施していこうと思います。
お話はいくらでもしますので、勉強会へのお誘いよろしくお願いします!

Serverlessconf Tokyo 2017で登壇してきました

Serverlessconf Tokyo 2017のカンファレンスのほうで登壇してきました(

前日にワークショップがあったのですが、そちらのほうには未参加)!

 

有料イベントというのでどれだけ集まるのかな?って運営者目線でも

興味のあるイベントでしたが、450名を超える方が参加されていたようで

活気と熱気に満ちてました。

 

cloudpackとしてブースのほうも出していたので、いろいろサーバーレスの質問を受けましたがその中でもLambdaの発火の頻度を確認してくる方が、ポツポツいて、

開発中でもポツポツあたるので、本番大丈夫でしょうか?って不安というお話が

あり、そこは設計でカバーしましょうって話をさせていただきました!

 

ブースに休み時間に立ちながら(休み時間以外はcloudpackのR&Dセクションのメンバーに対応してもらいました。休みの日なのにお疲れ様でした!)、
・"サーバーレス"を語るときに僕が語ること
・Continuous Delivery strategies for serverless world
・サーバレスアーキテクチャによる時系列データベースの構築と監視
・Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤
Google Cloud Platform で実現するServerlessの今
・Open source application and Ecosystem on Serverless Framework

を聴いていたのですが、

"サーバーレス"を語るときに僕が語ることの前半部分や
Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤
lambda部分のリカバリーの話など、だいたい言いたい事が語られていたので、

自分の資料の説明の時にそこらへんはさらっと流してしまったので、

ちょっとあっさりしたしゃべりになってしましました資料はこちらになります汗

おしゃべりらいよんちゃんのプログラムの部分はLambdaでどうパフォーマンスを

プログラムレベルで出すかの自分なりの答え(キャッシュ・マルチスレッド)だったので、力を入れて話す予定でしたが、時間も30分の中でサーバレス開発セクションの

全てを話す事ができる事はそもそも不可能なのでさらっとなぞっただけになりましたが、またどこかで話ができればと思います。

 

全体的に言いたかった事は、クラウドの各サービスの機能については期待しても言いが、性能に期待するのはやめたほうが良いって話と(設計でカバー)、

コンペで発注する方は、開発の金額だけを見るのではなく、運用まで含めた金額でしっかりと見て欲しいという事が伝われば自分的には成功なんですがいかがだったでしょうか?

自分的にはサーバーレスはSaaSやAIの時代に進む、プログラム系エンジニアとしての

最後の砦?的な存在と思っていますので、クラウド上でLAMP構成とかで既存の開発を行うのも良いですが、クラウド上での設計力やプログラム力が問われるサーバーレスアーキテクチャーにエンジニアもぜひチャレンジして頂ければともに、

発注側も安いってキーワードだけに過剰に反応せずに、自分達がもし、運用するかも?って考えたら、ちょっと見た目の初期投資は高くなるかも知れませんが、

開発期間に比べ運用のほうが圧倒的に長いので、トータルで考えていただければと思います。

 

 

あとサーバレース全般とサーバレスな動画配信とLINE BOTと番組宣伝システムに関するご相談はお気軽にこちらから↓↓↓↓↓↓

AWS導入相談、お見積りについてのお問い合わせ|AWS専業のcloudpack

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PagerDutyを導入してから1年と4ヶ月 現場の現在(イマ) 運用編&これから

NO OPSという言葉が嫌いで、サーバレスな時代がきたら、

インフラエンジニアが消えるのではなく
まず運用を意識できない開発者(※1)が消えると思いながら、
サーバレスをcloudpack大阪内で推進する比企です。

 

NO OPSの話しをしたいのではなく、今回の話しに出る運用を支えるバックエンドがPaaSやFaaSを使っているので少し記載させていただきました。

 

大阪のMSP開発ではPaaS(FaaS)・SaaSの利用を考えるところから始めます。
運用のコストももちろんですが、開発もコストであるところから、車輪の再発明はしないがキーワードなので、単純にプログラムをガリガリ描きたい方は向いてないかもしれません汗。

というところで今回はPagerDutyの運用からその先の話です。

 

通常の運用時のPagerDutyの課題として

【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その①] - 雑なA型によるクラウドとモバイルと運営と

【cloudpack 大阪 BLOG】pagerduty始めました・・・[イレギュラーな事態が発生した時の対応方法その②] - 雑なA型によるクラウドとモバイルと運営と

などもあり使った所感は下記

PagerDuty始めました 導入から二ヶ月実際のところどうなのPD?【cloudpack 大阪 BLOG】 - 雑なA型によるクラウドとモバイルと運営と

の記載がありますが今回は記載してないお話。

 

PagerDutyの利用料の増加

PagerDutyは便利ですが、利用者数が多くなると、利用料金がどんどん高くなってきます。
https://www.pagerduty.com/pricing/
普段運用のメンバーはインシデントがエスカレーションされるのでもちろん必須ですが、
運用と構築のメンバーが分かれているケースだと、どんどん人数が増えていくので、
注意が必要です。

構築メンバーPagerDutyを必要とするケースは、
①PagerDutyの設定とテスト
②定期的に確認するインシデントの全体量と傾向
ですが、①は設定も難しくなく、PDの設定自体は10分もいらないので、やるメンバーを集約できますが
②に関しては見る人を減らすわけにはいけないので、
Amazon Elasticsearch Service + kibana にLambdaから定期的にデータを突っ込んで
可視化するようにして、見る為だけのユーザー数を減ら為と、

AWSのMSP資格取得時にも必要となるインシデントの負荷情報のトレース(
毎月のインシデントを出力し、MSPのリーダー達がそれを見て負荷情報を確認・対応する)
の為の情報もPagaerDutyから抜き出せるようにしました(pagerdutyでも分析するモードはあるのですが、エビデンスを残すのは無理なのでエビデンス用の情報にフォーマットを加工して出力する機能も搭載)。

 

f:id:unioce:20161024134953p:plain

f:id:unioce:20161024135020p:plain

また上記のシステムにより引き継ぎ時の時間帯にslackへの投稿し、直近のインシデントの負荷状況も
次の担当者の引き継ぎを客観的な数字で連携することも可能としました。

f:id:unioce:20161024134651p:plain

 

 

PagerDutyの利用者による設定漏れとPagerDutyの瞬間的なサービス不通対応
PagerDutyは便利ですが、設定をミスっていたらもちろんインシデントは登録されません。
またPagerDutyは結構安定していますが、それでも100%のサービスを保証していないので
弊社側でシステムとして保管する必要があります。
そしてアラートメールは必ず飛ぶ設定をしますので、アラートメールをlambdaでhookし、
PagerDutyのインシデント状況をAPIで確認し、登録されてない場合はslackに投稿される&
未設定のインシデントということで、再度PagerDutyに登録してMSPのメンバーにエスカレーションされるように
システムを構築しました。
アラートメールの設定が漏れているとこの仕組みで検知はできませんが、それでも機械的にpagerdutyの設定漏れと
pagerdutyのサービスの漏れをある程度のタイミングで検知できるので、有効に機能しています。
 

・インシデント管理以外の活用
弊社は通常backlogでお客様とやりとりしていますが、24時間365日一人一人がつきっきりで見ることはできません。
また複数人で対応していますが担当者が未設定でお客様が登録すると漏れやすい状況となります。
なのでlambdaを利用し、担当者が時間外の場合(設定者のみ)、および担当者が未設定のものや担当がMSPグループに設定されたものは
slackとPDに登録されるようにシステムを作りました。
また運用に使っているGoogleカレンダーのイベント情報もPagerDutyへの登録とslackに投稿する(PagerDutyがクローズされた場合は
slackにも出力される&放置されるとslackにリマインド通知が届き、他の方や登録した人が気がつく)機能も実現しました。

 

上記を踏まえた現在のシステム構成は下記となります

f:id:unioce:20161024134534p:plain

 

現在の取り組みとPagerDutyのwebhooksの課題
PagerDutyでの可視化が行われたことにより、自動化やシステムで補助する監視対象が客観的な数字で追えるようになりました。
完全な自動化は車の自動走行と同じく、なかなか心理的な面で厳しい部分もありますし、
自動化ありきのインフラは論理的にはできますが、実際のニーズと違うケースも多々あります。
なので、現在MSP開発チームではPagerDutyのwebhooksをAPI Gateway&Lambdaでhookして、踏み台サーバーを経由して
自動で問題のサーバーに入り、サーバー内部の情報を取得しエビデンスを残したり、コマンドを実行するARAYASHIKIのαテストを開始しています。
この仕組みを利用しいずれAWSのDevice Farm上のiOSAndroid端末で自動で動作確認を行いそのエビデンスも自動で取得する事も可能となります。
ちなみにARAYASHIKIを実現する時になぜか最初webhooksから登録されていたけど途中から登録されなくなる謎の不具合の遭遇しました。
問題はPagerDutyのwebhooksが3秒以内に応答を返さないとblacklistに登録され、webhooksが無効化されてしまうとの事だったので
pagerdutyに近いと思われるリージョンにAPI GatewayとLambdaの配置をし、Lambdaの中の処理は受付のみで、SNSで再度lambdaを
callするようにしてlambdaの処理時間も最速で非同期で終了するように対応しています。
ちなみにwebhooksの課題は他にもあり下記は特に気をつけたほうがいいです。

さらばHubot さらばEC2。API GatewayとLambdaで始めるMSPのIT化フェイズ3(その1)【cloudpack 大阪 BLOG】 - 雑なA型によるクラウドとモバイルと運営と

こんな活動をtwiter上でつぶやいているのPagerDutyの中の人がわざわざ来てくれて、いろいろと意見交換できて非常に有意義な時間を
過ごしましたが、pagerdutyの世界の利用状況を聴いて、世の中にはまだまだスゲーやつがいるなと再認識させていただきました
(ちなみにプレゼン中に5回スゲーと言っていただきましたw)。

 

今後はPagerDutyで操作するUIでMSPの方がARAYASHIKIで取得したサーバー情報を見て、作業の対応や問題なければクローズするPDへの

操作とARAYASHIKIの情報をMLに学習させ、作業の半自動/全自動化ができるようになり、
本当に集中したい仕事にMSPのメンバーの方々ができるようになればなと思いながら、

あとはMSP開発のメンバー達に託し、自分は2014年8月からのlambdaの
開発/運用ノウハウをベースに9月からチームとしてサーバレスに取り組んでいきます。

 


※1 運用を意識できない開発者
NO OPSで言われるのは単純なオペレーションの廃止ですが、そのほとんどは
開発者が運用を意識せずにシステム開発を行い、その業を運用側が代わりに背負って
日々運用しています。
サーバーレスな時代で、”もし”インフラエンジニアが減れば、
運用を意識できない開発者の垂れ流していたアラートがそのまま壮大なブーメランとなって
帰ってきて、それに耐えきれない運用を意識できない開発者が消えていくと思います汗

インシデント管理システム「PagerDuty」を導入してから1年と4ヶ月 現場の現在(イマ) 導入編 【cloudpack大阪BLOG】

これまでのBLOGでも記載しましたが

インシデント管理システム「PagerDuty」ってご存知でしょうか?
監視対象のサーバーでインシデントが発生した場合、

通常はアラートメールを受信して担当者の方が対応しますが
そのアラート数が、一人で捌ききれない量だったり複数人だった場合・休みの日に通知を受けたくない場合に有効なのがPagerDutyです。
https://www.pagerduty.com/
電話でもインシデントの通知を受け付ける事ができるので、一人運用にも有効です!

日本語での説明は下記BLOGで記載しています。
【cloudpack 大阪 BLOG】pagerduty始めました・・・[説明編]
http://unioce.hatenadiary.jp/entry/20150713/1436787871


cloudpackではPagerDutyを2015年の5月から導入し、

現在に至りますが最初自身一人で導入してからPagerDutyを基盤の

一つとしたMSP開発チームの立ち上げを行い、
MSPサーティフィケート(次世代MSP)の認証も2回認定をいただいた背景の

裏側にはPagerDutyのシステムやデータの可視化が有効に働きました。

cloudpack、AWSのMSPプログラムとビッグデータ コンピテンシーの認定を取得|AWS専業のcloudpack

AWSパートナープログラムにおける『次世代MSP』の認定を取得|AWS専業のcloudpack

 

そんな中、8月に自身のセクションから
大阪の別セクションにMSP開発チーム自体を移動したので、
もう自分のBLOGで新規のアップデートはあまりないなと思い、
今までcloudpackのMSP(開発)内で、どのようにPagerDutyを活用していったかを

記載します。

 

導入の背景
導入当時のcloudpackですでに毎日うん千という、監視サーバーからのアラートメールを
MSPのメンバーがメールを見て、各々が申告して対応していましたが、

多くのインシデントを複数人で
漏れなく対応するのは現実的ではなくなりつつありました。
またcloudpackでは運用の冗長化(DR対策)で大阪にも運用の部隊があるので、拠点を超えての
阿吽の呼吸は事実上不可能で、インシデント管理でのシステム化は必須で、自社内で作ろうとする動きもありましたが、
PagerDutyというインシデント管理システムがあり、監視のSaaSでたくさんの監視サーバーやクラウドのサービスに対応
https://www.pagerduty.com/integrations/
しているので、PagerDutyの導入となりました。

 

試験導入と課題
試験的にまず導入してみようとのことで、10件程のサービスの監視(nagiosとsensu)を行って試験運用してみました。
そこで発生した課題は、下記で記載していますがスケジュールの作成問題でした。

【cloudpack 大阪 BLOG】pagerduty始めました・・・[いきなりの制約回避編 スケジュールとエスカレーションポリシーのハマりどころ] - 雑なA型によるクラウドとモバイルと運営と

cloudpackのスケジュールが特殊とは思わないので、もしスケジュール作成のスクリプトが(
google apps script版でコードは雑w)欲しいいって方は個別にお渡ししますのでメッセージください。

 

本格導入と課題
試験導入で現在の運用に対するPagerDutyの有効性はわかったので、本格運用に入ろうしましたが、ここで色々課題がでてきます。

 

・圧倒的に多い監視対象
2015年5月の時点でnagiosだけで500以上のサービスを監視していたので、手動でやると間違いなくミスをするので
nagiosの監視設定を抽出し、必要な項目をスクリプトに食わして監視設定をスクリプトで自動に対応するようにして実行しました。UIでポチポチなんてやってれません汗

 

・古い監視サーバーへのpagerdutyのpluginのインストール問題
弊社のnagiosサーバーは、複数個あります。多くのサーバーを監視しているサーバーはpluginの導入はうまくいったのですが
古くからある監視サーバーでpluginを普通にインストールするのが厳しいものがあり、本番運用もしているのであえて無理やり
pluginはインストールせずに、メールでのインテグレーションの対応にしました。
https://www.pagerduty.com/docs/guides/email-integration-guide/

 

導入に関してはリアルな運用含め色々と苦労もありましたが、

アラートメールで対応の漏れのないインシデント管理は
我々のようなMSP事業者としてはシステムで対応しなければまず無理なので、

MSP依頼時にはそういうシステム使ってますか?
ってのをまず聴いてみるのもありかもですね(slackで通知を受け付けてますってのは

平和なんだなーと思いますw)。

 

PagerDuty関連でのお仕事のお話があれば是非比企まで連絡していただければ、

ZOOMなどのTV会議でも対応可能ですのでよろしくお願いします〜

次回は運用時からPagerDutyを含めたエコシステムを記載します。

サーバレスアーキテクチャーを運用に適応するために考慮する事【cloudpack大阪BLOG】

PaaSが昔からあるのにLambda+API GateWayが出てサーバレスアーキテクチャーが、もてはやされ出してから時間が経ち、BOT作成人気もあってLambda+API GateWayで試してみた系の話が多くなってきましたが

運用するにあたって考慮すべき話が出てこないので、Lambdaで実現したプログラムを

実際に運用してみて引っかかったり、問題になった部分をちょっと書いてみます。

 

ちなみにサーバレスアーキテクチャーの記事は

や、弊社が出しているLambdaの開発者向けホワイトペーパーは

からダウンロード可能ですので是非みていただければと思います。

 

考慮する点ですが、運用してみた中で、?と思った件があります。

開発時に設定や実装ミスなどもありましたが、エラーが発生せず、
イベントが発火しないケースが存在しました。
問い合わせ時に参考にする記事もあるので一読されることをお勧めします。

 

クラウドではインスタンスが落ちても良い設計をするという話がありますが
サーバレスアーキテクチャーな設計では、エラー時の処理はもちろんの事、
イベントが発火しなかった場合のリカバリーする方法を設計しておく必要があります。

具体的にはイベントが発火しなかった場合、スケジュールの処理などで発火しなかったものを救うなど。
それならいっその事スケジュールの処理で全てすくえば良いって話もありますが、ある程度リアルタイムかつ効率良く処理させれるイベントドリブンな処理は魅力ではあります。

SLA100%ではない現状では、動作しなかった時の検知方法とリカバリー処理は是非とも考えておいたほうがいいです。
※IaaSで実施していた場合も、本当はいろいろあったのですが、

監視方法などが確立され、監視システムのスクリプトなどを

うまく活用して運用してきたのですが、サーバレスアーキテクチャーは

まだこなれてないので、スタンダードな手法がまだ確立されていないのが現状だと思います

 

またシステムの重要度にもよりますが、

Lambdaのメモリ使用量や処理時間などのリソース監視に関しても、注意を払う必要があります。

少しずつメモリ使用量や処理時間が増えていって、ある日突然リソース不足でひたすらエラーに陥いり、あとでリカバリー処理が大変にならないためにも日常のリソース監視

も考える必要があるケースもあります。

 

あとエラーの通知などもよくよく考えずに実装してしまうと、

運用の方がいない場合は開発者の一人24365運用が始まったりします汗。

 

IaaSなどに比べ、開発者にとって、さらにお手軽に実装できてしまう、

PaaSやLambdaですが、運用を考慮した設計と実装を行わないと、

今まで運用している方に押し付けてきたプログラムの未完成さが

フィルターなしにそのまま返ってきます。

 

サーバレスアーキテクチャーやPaaS以上が主流になれば

インフラエンジニアや運用する人は、いらなくなるって極端な話もありますが、

インフラエンジニアや運用してくれる人が、もしいなくなれば、

運用を考慮できない開発エンジニアもその後に淘汰されるってのが

サーバレスアーキテクチャーの案件や、MSP向けのサービスを開発し

運用してきた自分の今の意見です。

 

サーバレスアーキテクチャーで言葉だけではないDevOpsが理解されるようになればと思います。