2017年6月のssmjpに参加してきました。

タイトルと発表者はそれぞれ以下の通り

信頼できる情報源の探し方 @YuhoKameda

Kamedaさんは最近blogを書いていて、その中で情報をどこまで追っかけると信頼できるか検証しており、1日で1500～2000記事くらいをFeedlyで見ているとのこと。

Kamedaさんとしては、信頼できるソースとは

・一次ソースへのリンク等、その記事が基にした情報源を書いてある

・お役所などかたいところにインタビューしたような記事

・ベンダから出ている公式な情報

・セキュリティインシデントなどのときは被害者が直接出している情報

信頼できないソースとは

・書いている人の個人的な見解が入っている

Kamedaさんのやり方としては、MSの毎月出ているWindowsUpdateの場合だと

・MSの公式サイトに載っている英語ページ

・MSの公式に載っている日本語のページ

・MSの公式をもとに書かれたメディアの記事

の上から順に信頼できるソースとして普段は見ているそうです。

また全員が必ず一次ソースを見る必要はなく、現場のエンジニアはできるだけ一次ソースを参照したほうがいいけど、役員などのクラスの人はメディアのニュース記事で十分ではないかとのこと。

ビジネスに貢献するための運用設計　波田野さん

波田野さんの運用の話。

運用ってやっている方も何をやっているかうまく説明できない。

運用の定義からしましょうということで運用とは「サービスデリバリ」と定義していました。

運用をサービスデリバリと定義することでサービスとデリバリという2つの専門性で捉えられるとのこと。

サービスとは顧客の問題を解決することであり、デリバリとはサービスを顧客に安定的に提供すること。

つまり運用とはサービスデリバリのことであり、サービスデリバリとは顧客の問題を解決し安定的に提供することであり、運用とは実質フルスタックのことである。

とはいえ1人でフルスタックは辛いのでチームでフルスタックができるようになるといい。

エンジニアは現場視点で物事を考えるので現場にとって最適な解をとりがちだが、本当はビジネスや会社にとって最適な解を取る必要がある。

　→現場が楽になることと会社の利益になることがぶつかりがちになることが多いため

現実的な手段として、作業する際のマニュアルや運用に作業を依頼する際の手順をしっかりと整備して記録に残るようにすることで運用がどれだけ顧客の問題を解決できたか客観的に評価できるようになるといい。

波田野さんは品川のJAISTサテライトキャンパスでビジネスモデルキャンパスを学んでおり、それを基に考えているそうです。

AWS LambdaとDynamoDBがこんなにツライはずがない @nekoruri

[slideshare id=77408438&doc=20170630ssmjppainfularchitecture-170630184007]

@nekoruriさんのAWS LambdaとDynamoDBでサーバーレスなシステムを作ったお話。

純粋にLambdaとDynamoDBがつらいというお話でした。

ここの話は一部しか理解できなかったのでメモってあることをまとめただけです。

構成としては

BLEメッシュ → SORACOM → Kinesis Stream → Lambda → DynamoDB

Lambdaの辛い点

・ログがCloudWatch Logsに保存されるがどこかでバッファされてるのか遅れてくる

・あらかじめ確保するメモリのサイズを指定しないといけないが、実際に消費したメモリサイズはログを見ないと分からない

・EC2も使えるけどスケールに時間がかかりすぎる

・KinesisからLambdaにデータを渡すとき基本的に1シャード1プロセスでありLambdaは連続実行している限り同じプロセスを使いますが、あくまで1シャードに対して割り当てられるのが1プロセスであり、裏で複数のプロセスが起動していて待機していないとは言っていない？

・Networkレベルでの認証がないので認証はIAMRoleで頑張る

DynamoDBの辛い点

・DynamoDB自体がKeyValueStore(KVS)なのでデータが増えるとソートキーで頑張ろうとするとデータが分散せずにいつか死ぬ

・同様にデータが増えるとScanクエリでテーブルを全部舐めるのでいつか死ぬ

・DynamoDBは課金体系的に高くつく

・そもそもKVSだけでシステムを作るのが辛い

・Kinesis FirehouseとKinesis Analyticsが東京リージョンに来ればプログラムを書かずにシステムを作るのも夢じゃない

感想

Kamedaさんの話は最近WannaCryとかNeoPetyaとか各セキュリティベンダの出す情報が食い違ってて情報が結構錯綜していたので他の人どうしてんだろなーと思ってたところなのでそのへんをKamedaさんはどうしてるのかとか質問してみたりと自分の中では結構ジャストタイミングでの話でした。

波田野さんの運用の話は自分も最近はずっと運用の仕事をしているので現場は部分最適化しがちと言われたところで胸に刺さったりと耳が痛い。。。

nekoruriさんのLambdaとDynamoDBの話は、自分はLambdaで毎日一定の時間が来たり使ってるリソースが基準を下回るとEC2を落としたりとか、CloudWatchでAWSの利用料金の監視アラート飛ばそうとするとメールが来るのが結構遅かったりするので、Lambdaで監視してメール飛ばすようにしてたり程度なので実際にLambdaでシステム組んだことないなーと思いながら聞いてました。

DynamoDBにいたっては使ったことすらないんですけどね。

Togetterまとめ