AWS Summit 2017「全部教えます！サーバレスアプリのアンチパターンとチューニング」のメモ
AWS Summit 2017にて全部教えます！サーバレスアプリのアンチパターンとチューニングを聴講したのでそのメモです。 かなり詳しい話を聞けて大変参考になりました。 www.awssummit.tokyo
メモ
パフォーマンスをどう上げるか
プログラム側
各言語のベストプラクティス・最適化方法はそのまま当てはまるので、プログラムのパフォーマンスを上げておく
コンピューティングリソース不足
- メモリ設定
- 実際にはリソース全体のパフォーマンスの設定を意味する。
- メモリに比例してcpuのリソースも上がる。
- メモリ設定を上げることで実行時間が減り、パフォーマンスが向上し一方でコストが変わらないこともある。
- 適切なスペックを洗濯することが大事。低スペックからだんだんあげていって、処理時間が変わらなくなるスペックがあるので、そのスペックに決めるのが良い。
コールドスタート
起こる条件
- 利用可能なコンテナがない場合
- そもそも１つもコンテナがない
- 利用可能な数以上に同時に処理すべきリクエストが来た。
- コード・設定の変更をした
- これらの条件にあてはまなければ発生しない。コールドスタートは全体の1%くらい
コールドスタートが許容できないのであればLambdaを使うべきではない
速くするためには
- コンピューティングリソースを上げる
- 言語を変える
javaはコールドスタートが遅い。ウォームスタートの場合、コンパイル言語の方が速い傾向 - VPC接続ははENIの発生を伴うので必要がなければ使わない（VPCアクセスが必要なければ使わない）
これだけでコールドスタート時の10秒程度を削減する可能性 - パッケージサイズを小さくする
コード量の削減、不要な依存関係の削減、最適化ツールを使用するなど
アーキテクチャ
- 同期でinvokeすると同時実行数の制限にひっかかる
- 非同期でinvokeするのがスケーラビリティの観点ではおすすめ
api gatewayと組み合わせる場合、putの場合は直接呼び出すのではなくsqs kinesisに流し、それをイベントソースとして実行するべき。getはキャッシュする。
並列実行できるようにする
アンチパターン
dynamoがおすすめ
ログ
cloudwatchメトリクス、cloudwatchカスタムメトリクス、cloudwatch logsへのログ出力を行う
その他
- 障害を前提に設計する
リトライ、DeadLetterQueueを活用する
その他
スピーカーの西谷さんの著書が発売されているので、こちらを読むとさらに理解が深まりそうです。
実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2017/06/09
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Step-to-Rails-Expert.rb第7回を開催しました
5/22(月)にStep-to-Rails-Expert.rb第7回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- 議論
- 懇親会
という形で進めました。
会の様子
本家マストドンcollaboratorの@ykztsさん、pawooの中の人の@alpaca-tcさん、friends.nicoの中の人の@masarakkiさんを筆頭に、プライベートでマストドンを運用している方が多く参加して頂き、ソースレベルの質問から、企業で運用している人たちの悩み事まで色々有益な話が聞けました（議事メモに書いていいのかなみたいな話もありました笑）。懇親会もかなり盛り上がっていて、非常に良かったです。 詳しい内容は議事メモをご覧ください。
反省点
- ファシリテートはかなり反省点あり
7~8人と10人以上はやっぱり違う。今回は初参加の人も多かったので、その点も雰囲気が違った。もう少しうまく進めたい。 - 会の説明や進め方を説明した方が良い
- 議事メモのレイアウトは改良の余地があり
- 議題募集はGithubにてPRで追記してもらうような方が良い？ 今の方式だと誰にも質問できないし書き込みづらい。初見殺し。
個人の課題
今回も実際にマストドンを作っている方々から色々アドバイスを頂いたにもかかわらず、それを復習しきれていないです。ここ数回でも同じような感じで、色々学ばさせて頂いたことを100%飲み込むような時間を取れていないような現状が良くないと感じています。とはいえ、4週間後には次の開催が待っているのでその準備も必要だし、復習&準備が中途半端になっているような現状があります。その他にも、せっかく習慣づいていたOSS活動も最近はあまりやれていない（興味のあるSorceryの開発自体が進んでいないのもあるが）、フロントエンドをしっかりと勉強したいなど、やりたいことが多すぎるので優先順位をしっかりつけ進めていきたいです。
今後の企画
通常の会の方法とは異なる企画を行おうと考えています。 ベースとなるRailsアプリ、追加する仕様を開催側で用意、勉強会当日までに仕様の機能を実装し、当日はそれらのアプリを参加者でレビューしようという企画です。 書いてきてくれた人は会社以外の人にレビューしてもらう機会、そうでない人もレビュー内容を聞ける機会を得られるのでかなり学びのある企画だと思います。 懇親会で神速さんを始めみなさんから色々アドバイスを頂き考えた結果が以下です。
- アプリはTodoアプリ
単純なものは簡単に作れるが、リッチでインタラクティブなviewや、タグ、期限到来の通知、一括削除、todoの終了/削除などの状態管理、間違えて終了してしまったtodoを戻すなど、仕様を増やすとそれに従い難易度が増加するので、様々なレベルの人が楽しめる - 実施回数は数回
仕様を徐々に増やしていくが、最初から全体の仕様をオープンにしない予定。これにより、変更に強いアプリの設計・実装の仕方についても議論できる。実施は隔月かも。 - 課題
2回目以降から参加された方も楽しめる方法や、そもそもアプリ作ってきてくれる人いるかな・・など
色々準備があるので、次々回で実現する目標で動いています。次回実施時もしくは懇親会で企画について相談するかもしれないので、もしご意見ある方で参加されている方は色々リクエストください。こういう企画はよちよちさんが実績&知見があると教えて頂いたので、企画の説明やリポジトリを参考にさせて頂こうかな。
次回について
次回は6/26（月）にエラー通知/モニタリングというテーマで実施予定です。 Airbrakeなどエラーモニタリングツールの使い心地は？どういう方法で通知している？どのような体制でエラーに対応している？などの疑問点や、 オオカミ少年のエラー通知に誰も反応しなくなって問題が起きた・・などのツラミなど、様々な視点から議論しましょう！
「社内横断の技術組織を終わらせました」を読んで思ったこと
を読んで、思ったことがはてぶコメントに書ききれなかったから、ブログで書いた。思ったより長くなった。 割りと思ったことベースでそのまま書いているので駄文です。あと、会社の元記事も合わせて読んでいますが、認識に間違いがあったらすみません。
はじめに
まず最初に、筆者の方には辛い話を共有していただけて本当にありがたいです。色々勉強にになりましたし、今後私にもこのような知見が生きるときがあると思うので、参考にさせて頂きます。 以下に書くことは誰への批判でもありません。客観的に聞いて考えたことです。
思ったこと
複数の事業部が荒く速く進めていることで生じる問題を抑制するために横断的な別の組織が責任を持つようになると、インセンティブが異なる組織になってしまうが、そこに歪みが発生してしまったのだと感じた。事業部は速く進めようとする方にインセンティブ向くけど、横断組織は問題を抑える（極端に言えば0にする）方に向き、異なるインセンティブが生じ断裂を生んでしまう。事業部は速く進めれば勝ちだし、横断組織は問題を起こさなければ勝ちという構図に陥っているように見えた。本当は「なるべく」速く「なるべく」問題を起こさないのが目的なのに。 なので、横断組織はレビューを過度（？）に行い、新技術導入も同類のプロダクトを比較するという慎重な姿勢にならざるを得なかったのではないかと推察している。
新規技術の導入に関して、クリティカルに生じている問題に対しての技術導入は（誰が行っても良いが）横断組織としてでなく事業部としての仕事の成果として計上するような方式で進める方が良かったのではないかと考える。そうすれば、必要以上に慎重になる必要がなく、「とりあえず」今の問題を抑える技術導入ができればOKラインだろうし（横断組織の技術導入はこの成果ではOKラインは出ないでしょ）。逆に、ある程度長期的な新規技術導入なら、しっかり調査&比較して決断し、横断組織の成果とすれば良いと思う。 レビューに関しても、横断組織は推進だけ行い、とりあえず粒度は事業部ごとに自由度を持たせ事業部の責任にした方が良かったのかな。
まとめると、やる内容で責任主体を分けるだけでは不十分で
- インセンティブの向き
- 施策内容の目的（喫緊の問題に対するパッチなのか長期的な根本解決なのか）
- 施策内容の緊急度
あたりで責任の主体を分けるのが良いのかなと思った。
会社名出ている元記事のミッションを見ていると組織は割りと中・長期的な方向性が想定されているのに、実態はそうでなかったりしているので、中・長期的なことをやる組織が必要に追われ喫緊の課題を解決するようなミッションに追われてしまったのが不幸だったのだと思う。 横断組織で喫緊の課題を解決する場合は、もっと厳しいトップダウンではないと難しいのかな・・・
Step-to-Rails-Expert.rb第6回を開催しました
4/24(月)にStep-to-Rails-Expert.rb第6回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- 議論
- 懇親会
という形で進めました。
会の様子
今回のテーマは認可でした。主な内容としては以下を議論しました。
- テーブル設計・アプリ設計について
- Gem導入時に検討すべき観点について
- 認可Gemの比較や認証Gemの相性など
- 権限の管理について
人数が少なかったのですが、その分いろいろディープな話ができ面白かったです。個人的には、参照系ではcurrent_userからレコードを引っ張ることでシンプルに実装できるというテクニックが非常に参考になりました。
詳しい内容は議事メモをご覧ください。
運営について・感想
前回の反省点を踏まえ、議事メモは推敲したので、参加していない方からも見やすくなっていると思います。会場の雰囲気が伝わり参加したいと思って頂ければ幸いです。 あとは、実施中にスライドに移すブラウザのサイズが小さくて少し議論しづらかったので、会場の担当の方に教わって調整できるようにしたいなと思いました。
次回開催
次回は5/22（月）に開催予定です。テーマはマストドンソースコードリーティングです（予定）。 おそらく次回開催までに色々な勉強会で触れられると思いますが笑、
などを予定しています。マストドンソースの疑問点・指摘点の議論に関しては、Step-to-Rails-Expert.rbっぽく議論形式で行いたいと思います。ソースコードを読んでいる方も多いと思うので、その時に思ったことや抱いた疑問があれば、次回の議題リストに書き込んで頂いたり、参加して頂ければ嬉しいです。
Step-to-Rails-Expert.rb第5回を開催しました
3/24(月)にStep-to-Rails-Expert.rb第5回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- 議論
- 懇親会
という形で進めました。
会の様子
今回から、Speee様に会場を移し開催しました。何度か違う勉強会で訪問させて頂きましたが、相変わらずオフィスとは思えないくらいオシャレでした。。なんとコーヒーとクッキーを出して頂き、美味しく頂きながら議論を行いました（写真撮るの忘れた）。
議論の内容は議事メモをご覧ください。
いくつか挙げると、
sinsokuさんのLT
忙しいところ資料を作って頂き本当にありがとうございます。基本的な内容から、Railsでテストを行う際の注意点・便利Gemなど網羅的に説明して頂き本当に参考になりました。カバレッジ計測について
codecovをデフォルトの設定で使うと、一個も使っていないコードを無視されるのでカバレッジが正確に出ないという指摘などカバレッジ計測についての注意点は、使い込んだ人からでないと聞けない内容だと思います。テストの並列化について
などの話ができました。また、スタッフのtwo_sannによるgem作成時、Rubyのバージョンをどこまで担保するかという質問もあり、Gemのメンバーとしてメンテナンスされている方ならではの質問だなぁと勉強になりました。 個人的には「Gemにてmigrationファイル等のテンプレートをgenerateする機能についてどうテストするのだろう」と思っていたところ、Railsでgeneratorのテストをどう書いているか参考にしてみると良いかもとのアドバイスを頂けたので非常にありがたかったです。
運営について・感想
Speee様での初回開催だったので緊張していましたが、特に問題なく終えることができました。会の実施方法についても固まってきて、自分の中でも「ここまで用意すれば無事運営できる」というラインが見えてきているので、非常に良いと思います（この辺は私が慣れたという以外にも頻繁に参加してくださる方達によるところも大きいです）。
懇親会では色々相談に乗って頂けましたし、なんというかもう本当にありがたいです。この勉強会を開くことで本当に色々な経験や勉強をさせてもらっているので、一歩踏み出し勉強会を主催して良かったなと思っています。懇親会で「色々イベント主催されているんですか？」「いや、この勉強会が初めてです。他の人が主催した勉強会に出ても話すのが苦手であまり交流できなかったのですが、主催するようになって積極的に話せるようになりました」というやりとりをしていて、Step-to-Rails-Expert.rbを開催する前の自分を思い出し、技術的にも精神的にも成長したよななんて思ったりもしていました。
課題としては、議事メモを参加していない人が理解できる程度にまとめるのは非常に難しいと感じているので（その場で書くのも後で内容をまとめるのも）、まずはスタッフのtwo_sannと連携して工夫していきたいなと感じました。主催者がメモっているところに（特に初参加の人は）書き込みづらいと思いますし・・・。
あとは参加者の人数が少なくなってきてしまっているのが少し気になるので、工夫できる点がないか考えてみます。
次回開催
次回は4/24（月）に開催予定です。テーマは権限周りの予定です。
shimaさんから「デプロイ周りについて」という次回テーマの提案があったのですが、非常に面白そうなので逆にもう少し眠らせておこうという判断になりました笑
かなり面白そうで盛り上がりそうなテーマなので、もう少し経験値を積んだらぜひ取り上げたいところです。
Step-to-Rails-Expert.rb第四回を開催しました
2/27（月）にStep-to-Rails-Expert.rb第四回を実施しました。
step-to-rails-expert-rb.connpass.com
会の様子
- 自己紹介
- 議論
- もくもく作業
運営について
今回一番の反省は「もくもく会」なのか「フリーテーマの議論」なのか私が設定せずに進めてしまったということです。 一応、自分の中では「フリーテーマで議論し議題がなくなったら作業しても良い」というイメージでおり、開始時点では1点しか議題がなかったため「今回はもくもくメインになるのかな」と考えていました。 しかし、その後参加者が増え議題が追加されましたが、私がうまく話を広げられませんでした・・
原因として
- フロントエンドの話題は、自分に全然馴染みがなく話を広げることができなかった
というのがあったと考えています。
「そもそも〜ってなに？」のレベルだった私はどう話に参加して良いかわからず、また、議題を出して話してくださっていた方達も主催者が黙ってしまうので喋り続けづらかったのでしょう、すごく静かに作業する空間になってしまいました。。。
- 質問しまくる
- わからないことをスクリーンで調べる
という対応でせっかく話してくれている方を困らせないように対応すべきだったと反省しています（そしてその方が私も勉強になったはず）。
しかし、一番の原因は自分の中で「もくもくにするか」「あくまでも議論中心にするのか」のどちらに会の方針をするのか決めきれていなかったのが原因かなと思います。 そういう迷いがあったからこそ、質問したり話に入ることができず、中途半端な対応になってしまったのだと思います。
今後はフリーテーマの会で議題がない場合でも、基本的には何かしら話す（懇親会のようなイメージ）という方向性にしようと決めました。 せっかく議論形式の勉強会なので、話せないのはもったいないなという考えからです。また、懇親会で気になったことなどを話しているだけで非常に勉強になっているので、テーマが決まっていない時はその雰囲気やメリットを本番の会にも持ち込めたらという考えもあります。
業務都合で準備が完璧には終わらずにフリーテーマになってしまうことは正直これからも出てきてしまうと思うので、方針や運営方法でカバーし自分にも参加者の皆さんにも有意義な会にできればと反省しました。 今まで参加してくださった方で、「議論する会」という認識でやることを持って来ていない方もいらっしゃったので、本当に申し訳なかったです。
お知らせ
初回から現在までアニメイトラボ様に会場をお借りしておりましたが、アニメイトラボ様が引越しされるとのことで、次回から会場を変更させて頂きます。 アニメイトラボ様には、実績のない勉強会にもかかわらず今まで快く会場をお貸しいただき本当に感謝しております。
新しい会場は株式会社Speee様にお借りすることになりました。快く引き受けて頂き本当にありがとうございます！
次回開催日は3/27（月）の予定です。テーマはテストの予定です。大江戸Ruby会議の次の週なので、大江戸の話もできたら面白そうですね。 是非ご参加ください！
OSS Gate東京ミートアップにメンターとして参加しました
OSS Gate東京ミートアップ2017-02-20にメンターとして参加しました。過去ビギナー・開発者と参加して、メンターとしては初参加になります。 oss-gate.doorkeeper.jp
やったこと
OSS Gateの基本的な進め方として、
- 対象プロダクトを決める
- プロダクトを動かす
という流れなのですが、私が担当したビギナーさんは対象プロダクトも決まっており、かつ予習としてテストを回してきていたので上記のプロセスを行う必要はありませんでした。 さらに動かした上で気になる箇所が決まっていて、教えることがないという状態でした笑
テストを回した時にスキップするケースが気になるとのことだったので、まずスキップするテストケースを探しました。 対象プロダクトはあるサービスのAPIを叩くRubyライブラリだったのですが、そのサービスに登録しないと取得することができない認証ファイルがあり、その認証ファイルがローカルにないためテストがスキップされていたのでした。 また、その調査の過程でテストでURLにアクセスしており、モックを使っていないという問題も見つかりました。
問題として
- 認証ファイルのダミーも用意しておくべきではないか
- URLを直接叩くのではなくモックを使うべきだ
という2点が浮かび上がったので、まずは後者に関してissueを送るように進行し、結果として、issueのテンプレートをある程度書くところまで進めることができました。
感想
- 最初に具体的な進め方の指示がもらえるので、かなり進めやすかったです。会として完成していてすごいなと思います。
- 困ったらサポートメンターの方に質問できるので、その点でも安心でした（個人的に気になった技術的な質問もさせてもらいました）。
- 担当ビギナーの方は事前にかなり進めてくれてきて少し方針に迷いましたが、進め方をサジェストしながら進めることができたかなと思います。
- 実際に一緒に解析・調査しながら進めたので私も非常に楽しめたのですが、ビギナーさんも同じように楽しんで参考になったのか少し心配です。
最後に
次回は3/30（木）19:30開催予定です！ 非常に面白いのでOSS開発に興味のある方は是非ご参加ください！
