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開発に興味のある方は是非ご参加ください！
Step-to-Rails-Expert.rb第三回を開催しました
1/30（月）にStep-to-Rails-Expert.rb第三回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- スタッフのLT
- 議論
- 議題が終了したのでフリーテーマでの議論
- 懇親会
という形で進めました。
会の様子
スタッフの@two_sannのLT（しかも初LTだそうです！）でスタートしました。
Carrierwaveしか使ったことがない人が多数だったため、Carrierwaveとの使い方の差を知ることができ面白かったです。
参加者はPaperclip未経験の人が多かったのですが、Paperclipの議題が上がった時、ソースやREADME.mdをみんなで読み込み結論を出せてたのは非常に良かったなと思います。
知っている/知らないで済ますのではなく、その時にきちんと調べるということが参加者みんなでできる会というのは、中級者向けの会として非常に有意義に思えました。
ところで、参加者の数がいつもに比べ少なく少し不安だったのですが、人数が少ない分いつもより話しやすくなり、面白い会でした。 今募集している参加人数の上限から減る分には特に問題なく運営できそうです。 内容に関して、個人的にはテストやRubocopについての話が聞けて大満足でした。
内容について詳しくは議事メモをご覧ください！ また、何か聞きたいことありましたらSlackチャンネルもオープンしているので、気軽にご参加ください。
運営について
議題をオープンにする
今回から、議題を最初に集めそれに基づき議論するという形式にしました。 残念ながら、スタッフ以外にはあまり書き込んでもらえませんでしたが（その中でも書き込んでくれた方ありがとうございました！）、色々な人の意見を取り入れるという点でも、この方法で当分は運用していきたいと思いました。 書き方やどのようなことを書いて良いのか不透明という反省点があるので、参加したことがない人にもわかりやすいように、過去の議題のみまとめ周知する必要性を感じました。テーマを決めるか決めないか
こちらは柔軟にやっていきたいと思います。 主催者が勉強したいという都合からなるべくはテーマを決めたいと思っていますが、 フリーテーマもちょうどその時話したいことを話せるというメリットがあるので、必ずどちらにすると言いづらいです。 両方ともメリットがあるので、特にテーマの希望が集まらない・準備が間に合わない時はフリーテーマにしようと思います。
次回開催
次回は2/27(月)に開催予定です。テーマは募集開始時にお知らせします。
募集開始とともに議題を募集するので、参加予定の有無にかかわらず是非書き込んでください！
そしてお時間合えば是非ご参加ください！
Step-to-Rails-Expert.rb第二回を開催しました
12/5（月）にStep-to-Rails-Expert.rb第二回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介 & 当日のやること発表
- メンバーの自己紹介
- もくもく開始
- やったこと発表
- 懇親会
という形で進めました。
会の様子
今回はもくもく会ということですが、元々は議論形式の勉強会ですので「作業するのも質問するのも自由」という形で進めました。 参加者の方があるケースについてのルーティングの書き方の質問をしたところ、参加者みんなで考えるという形になりました。
- resourcesなどのDSLを使うべきか否か
- ルーティング設計の注意点・ノウハウ などの話が出てきて、非常に勉強になりました。
また、電話決済サービスを立ち上げている方が参加してくださり、技術の話や苦労話も聞けて、非常に有意義でした。
毎回議事メモを公開していますので、githubのStep-to-Rails-Expert.rbもしくはconnpassのページよりご覧ください。
運営について
第二回は、準備が間に合わないためもくもく会にしましたが、そのおかげで運営方針が固まりました。
というのも、前回のブログにも書いた今後の課題である議題をどう設定すべきかという点の対策を思いついたからです。
議題とは、例えばテーマがルーティングなら「リソースルーティングのはまりどころ」や個々人の疑問点・質問（resourcesとresourceはどう違う？）などを想定しています。
スタッフや私のみが議題を設定すると視点が固まるという予想はしていたので、運営が事前に用意したものに加え、当日に参加者へヒアリングして集めた疑問・質問を集め当日の議論内容にする方法で進行する予定でしたが、この方法にも議題が十分に集まるのかという懸念がありました。
しかし、今回参加者の質問によって議論が非常に盛り上がり、またそれが自分の持ったことのない疑問だったため、色々な人の疑問を取り入れる重要性を痛感し、事前にテーマのみ決めておき質問・疑問をオープンに募集する方法を取ることに決定しました。
具体的には
- 募集開始しテーマを公表する
- 募集ページのリンク先にある議題募集のmarkdownに議題を書き込んでもらう
- 当該テーマに関するLT（予定）
- 当日議論する
- 議題がつきた場合はもくもく会形式で自由に進行する
- その際に他の回の疑問点などを聞いて頂いてもOKです
- 議事メモを公表する
という流れで進行します。
なお、議題（疑問・質問）は、参加予定の有無にかかわらずオープンにします。
当日参加予定の人もそうでない人も書き込めるようにすることで、より多くの視点を取り入れられるのではないかと期待しています（細かいところでは、参加者に関して、参加者の質問・疑問を優先的に俎上にあげること、議事メモはオープンにするが簡易的なものなので参加する方が詳細に話を聞けるという2点を直接参加するインセンティブとして用意してあります）。
この方法を取ることで、勉強会をオープンにし直接的・間接的問わずいろいろな人との関わりを増やし、本勉強会が発展していけたらと思っています。
その他
- 懇親会はアニメイトラボさん近所のルノアールでまったりと行うことにします
アルコールないですが、いろいろ話しましょう。 - 気軽にいろいろ質問できるslack部屋を設置予定
- 勉強会でアプリレビュー会してみたい
OSSにライブラリは数多くあるので見るだけでも参考になりますし参加すれば鍛えられるのですが、webアプリにはOSSが少ないので（当たり前ですが・・）、趣味アプリを作りレビューして欲しいなと個人的に思っています。
次回開催
次回は1/30(月)に開催予定です。テーマは初回にリクエストを頂いた「画像周り」について取り上げます。
募集開始とともに議題を募集するので、参加予定の有無にかかわらず是非書き込んでください！
そしてお時間合えば是非ご参加ください！
Step-to-Rails-Expert.rb第一回を開催しました
Step-to-Rails-Expert.rb第一回を開催しました
Railsの中級者向け勉強会であるStep-to-Rails-Expert.rbの第一回を2016/11/7に開催しました。
step-to-rails-expert-rb.connpass.com
当日の流れは
- 勉強会の紹介
- 今日の流れ
- 見学者の紹介
- 自己紹介
- メンバーの自己紹介
- LT
- 議論（当日の内容はこちら）
- 感想・次回お題目リクエスト
という形で進めました。 議論では、認証機能がテーマということで、主催者のLTからスタートし（スライドはこちら）認証機能を実装する際に使ったことのあるGemのアンケートを取り、使ったことのあるGemについて良かったこと・使いづらかったことを話すという形で進めました（当日の議事録はこちらにあります）。 今回は神速さん（@sinsoku_listy）とぷりんたいさん（@spacepro_be）のお二人が中心的に話す形となりました。お二人が色々な知見を話してくださるので非常に参考になり、また主催者として会の進行の方でも助けて頂き大変ありがたかったです。 また、議論する時の情報の共有ツールをどうしようと思っていたところ、ぷりんたいさん（@spacepro_be）がHackMDを紹介してくれたので、非常に助かりました。 これはかなり便利なので、次回以降も使わせてもらおうと思います。
個人的な議論からの学びとしては、deviseがomniauthを依存関係に含んでいて、omniauth連携をしやすいのでdeviseが良いという点が非常に参考になりました（ログインしたまま投稿する/つぶやくといった機能を実装したことがなかった）。
初回にもかかわらず、素敵な会場で参加者も集まり、議論も進んでいたので非常に有意義な会になりました。
また、「中級者と銘打ったことで参加しやすかった・興味が湧いた」や「既存の勉強会（特にかなり実績のある勉強会）は出るのを躊躇してしまうので、若いコミュニティで出やすそうだった」という意見は、自分が本勉強会を開催する目的の一部だったので、素直に嬉しかったです。
前者に関して、レベル別の勉強会を開催しようとすると、どうしても初心者向けが多くなってしまうので、それ以外の選択肢のモデルケースになればという思いがありました。実際に実施してみて、いくつか課題を見つけたので、今後実施していく中で、その辺対処できたのかできなかったのか正直なところを書いて行きたいなと思います。
後者に関しては「学ぶに行くのだからそういう心理的な障壁も乗り越えるべき」というストイックな意見や「わかる」という意見が出ると思いますが、今回のメンバーに表参道.rbの主催者である神速さん（@sinsoku_listy）（間違っていたらすみません）、五反田.rbの主催者であるmikamiさん（@sukechansan）に来て頂いたことを考えると、他のコミュニティの主催者&スタッフの方と今まであまり勉強会に出ていなかった方が交流して、より（扱うトピックの）レベルの高い勉強会にも参加するきっかけを作るという貢献が出来るのではと期待を持てました。
言うまでもなく、「自分が学べる場が欲しい」という自身の目的はこれ以上ないくらい実現されていました笑
また、お世辞でも「次回出たい」と言ってくださる方が多かったのは何よりです。
そしてアニメイトラボさんのオフィスはユニークでかつ綺麗すぎるので、驚いている方が多かったです笑
会場提供してくださったアニメイトラボ様、ロゴを提供してくださったセラリンさん（@Selime_0123）、初回開催までお手伝いしてくれたお二人（@ttwo32さん、@KoukoMatsumotoさん） 本当にありがとうございました。今後とも継続的に開催していきますので、引き続き何卒よろしくお願い致します。
最後に、初回実施して課題がいろいろ見えてきたので、書き出しておこうと思います（内部の話や個人的な話を含みます）。
課題
毎回参加者のレベルが異なるが、LTの内容や議論の流れは想定するレベルによって異なる。
これを事前に把握することは出来るのか（すべきか）。例えば上級者枠・中級者枠を作ったり、基準を提示して事前にGitHubにあげてもらう？みんな発言するためにはどうすべきか
上級者が話すと黙ってしまう（聞いているだけで勉強になるというのは個人的にも理解できる）。しかし、上級者だけが話す形になり、話す人数が少ないと負担が増えてしまうのではないか。持続可能な進め方を考える必要がある。
また、中級者や、初級者に近い中級者の方も発言（質問）とかすることで、他の同じレベルの人も勉強になる部分があると思うので、ある程度発言してもらいたいし、そのためにはうまく話をふる必要がある。 話さない問題は、主催者の議論の進め方以外にも、ある程度の回数実施して、参加者の中で顔見知りができたり雰囲気がわかってくれば改善するのかも。あとは多分私の緊張が伝わってやりづらかったりしたと思う。 サービスを運営している会社と受託のみしている会社、両輪の会社、という勤めている会社による文化の違いとかも知りたいなと思うので、やはりいろんな人が発言するの大事。
この辺考えると、初中級・中級・上級というレベルの基準をこちらから提示して、事前に提出してもらい、また、自己紹介で提出したレベルを言うようにしてもらい、自分で把握できれば、話が振りやすくなり、結果的にいろいろな人が発言できるようになるかも。
反省点
今回の参加者レベルでは、LTはもう少し踏み込んだ内容で作るべきだった。ただ、やはりその対応をするためには事前にレベル感の把握が必要。
話が切れた時用の議題をいくつか用意しておく メインテーマの他にサブテーマをいくつか用意しておく。 サブテーマを後出しにしておくと、私の精神衛生上よくなかったり、無駄にその話を（私が）引き延ばそうとするインセンティブが生じるので、事前にサブテーマを公開してサブテーマが尽きたら自由時間という風にすれば良いかな。初回の様子を見ていると、その状態になっても各々席の近い人やレベルが合う人と話をするだろうと予想できるし、話をしない人は他の人の話を聞けるので（懇親会状態）、他の人の話を聞いているだけでも嬉しいという人のニーズも満たせるし、少なくとも（私が）無理やり話す伸ばすより健全だと思う。どうしても形式上、その場にならないと予期できないことがあるので、精神衛生上割り切りも必要。
ハッシュタグ考えてなくてすみません。準備不足でした。つぶやいてくれている方いたので、申し訳ないです。次までに考えておきます。
勉強会紹介のスライドを作る
スタッフについて
@ttwo32さん、@KoukoMatsumotoさんに初回開催まで手伝ってもらっていました。 最初は「意見もらえたら嬉しいな」くらいのイメージで考えていてました。もしやる気があるなら色々仕事もしてもらいたいなとも考えていましたが、そもそも無償でお手伝い頂いているのでお二人の無理のないようにしてもらうというのを最優先にして、自主的に手伝ってくれたところ以外のこと基本的には私がやるようにしていました。ただ、当初は開催まで時間があるので、そんなに（期限的に）負担になる仕事にはなってなかったのではないかと想像しています。一方、私としても割と良い感じに仕事を振れて、ありがたいなと思っていました。
しかし、開催が近づくにつれて、仕事量も増えていきお願いしたいことも増えましたが、同時に仕事の重さ（期限を切る必要が出て、「土日にやります」が難しい時がある）が増してきてあまり気軽にお願い出来なくなり、お願いすることがかなり減りました。というのも、期限を決めたり、成果物をチェックする必要があり、仕事を振ることでのお互いの負担が増えるだろうと考えていたからです。
そのような経緯で、お二人の立場をどう扱うべきか、という迷いが生じました。正直、スタッフとして扱うならもう少し仕事を振ることになるし、その結果色々厳しいことを言う必要性も生じるでしょうし、あまりご負担をかけたくないなというのが本音でした。
この意見を素直に伝え、「このままの関係もしくは純粋に参加者としての関係と、スタッフとしてしっかり入ってもらうのどちらが良いか」聞いたところ、@ttwo32さんはスタッフとしてやってくださることとなり、@KoukoMatsumotoさんは「当面は参加者として陰ながら応援します」ということで、純粋に参加者として参加して頂くことになりました。
ただただ私が作業見積もりをできておらず、きちんと最初にどのような関係性にするかを決めなかったのが悪いのですが、2人ともきちんと話を聞いてくださり、冷静に判断してくださったので本当に感謝しています。@KoukoMatsumotoさんは主にTwitterでの会場の募集、@ttwo32さんは議論内容に関する企画を主にやってくださり、初回開催に大いに貢献してくださいました。本当にありがとうございました。
@ttwo32さんへ、引き続きよろしくお願いします。知識豊富で心強いので、色々アドバイス頂けると嬉しいです。 @KoukoMatsumotoさんへ、BtoBの文化の話も聞いて見たいので、またきてください！
最後に
来月は12/5に開催予定です。connpassで募集しますので、是非ご参加ください！
OSS Gate（2016/07/30）に参加してきました
OSS Gateに参加してきました
OSS Gate（2016/07/30）にビギナーとして参加しました。 oss-gate.doorkeeper.jp
OSS Gateの詳しい説明は以下の記事に書いてあるので参照ください。
oss-gate.github.io kenhys.hatenablog.jp
感想
流れや実際にやっていることは他に書いてくださっている方がいるので、主にビギナーとして参加した感想を書きたいと思います。 私はビギナーとして参加したのですが、「本当に誰でもOSS開発に参加できるんだ」という感想を抱きました。
理由として、まず、経験者の方が実際にどのようにOSS開発に参加しているのかを体験することで、ハードルが下がりました。 ドキュメント修正のプルリクを実際に送るところまで体験できましたが、実際の体験だけではなく「その過程でどのような作業をすべきか」というところを教えて頂けたのはとても勉強になりました。
もう一つの理由として、OSS開発にも色々な役割があると意識できたという点があります。 設計/実装だけでなくドキュメント整備も大事な役割であり、ここは開発者の手の回らない箇所で初心者が役に立てる場所でもあります。 皆さんも経験があると思いますが、自分の開発に関するドキュメントは、自分が作り理解しているが故に穴のあるものになってしまうことがあります。 作成する時間がなくきちんとドキュメント化できないケースもあると思います。
さて、このOSSを使用することになると、公式ドキュメントに必要なことが網羅的に（さらには親切に）書いていないので、ハマることになります。 当然ググって解決策を見つけ進めることになります。ある人はブログに書き、またある人は自分だけの知識にしたまま、時間が経ちます。そして、また同じ轍を踏む人が現れます。・・・この繰り返しが起きるわけです。 しかし、本来「ハマってググる」作業は必要ない作業で、最初にハマった人がREADMEを修正すれば、他の人は「ハマらずに」進めることができたのです。
偉そうに書きましたが、このような心構えはOSS Gateに参加するまで私にはありませんでした。 でも、確かにドキュメントが分かりやすく書いてあれば嬉しいですし、その部分こそOSS開発初心者がOSS開発に参加するチャンスなのです。
例えばインストールでハマった場合、依存関係が足りないなら「何を事前にインストールする必要があるか」をREADMEに追記し、MacOSに関するインストール方法は書いてあってWindowsの方法は書いておらず 辛い思いをしたなら、READMEに不足しているOSの情報を追記すれば良いのです。ドキュメントが「自分のような初心者にとってわかりにくい」なら、初心者が分かりやすいように修正してあげれば良いのです。
こうすることで、同じ原因でハマる人は減りますし、最初から開発（設計/実装）の面で参加するよりハードルが低いと思います。
上記で書いた内容は「他人のため」という側面が大きいですが、もちろん本人にとっても良い面があります。 まずドキュメント修正レベルから開発に参加することで、参加していない時より開発をウォッチするインセンティブになり、 OSS開発の動きを学べたりコードを読む時間が増えたり、参加していない時よりも主体的に見られるようになると思います。 勉強やスキルアップのためにOSS開発をウォッチしたが飽きてしまった、もしくは漠然とよく分からなかったという人がいたら、ドキュメント修正レベルからOSS開発に参加し いろいろ学んでいくことをお勧めします。
最後に
メンターの方々、企画の方々本当にありがとうございました。
9/24に次回のOSS Gateが開催されます！メンターの人数が足りないそうなので、ビギナーの方だけでなくメンターでの参加も是非お願いします！ oss-gate.doorkeeper.jp
レポート: 【ランチセッション】クラウド時代のソフトウェアアーキテクチャ
登壇者
西谷 圭介様（アマゾン ウェブ サービス ジャパン株式会社 技術本部 ソリューションアーキテクト）
The Twelve-Factor App
codebase
- バージョン管理は当たり前、1つのコードベースから複数のアプリができるのは良くない
依存関係
- 環境に依存しないこと
- 依存関係を明示的に分離
設定
- 設定はOSレベルの環境変数に入れる
並行性
- スケールするときはプロセスごと増やす
マイクロサービス
hexagonal architecture
- 特定ポートに届いたイベントをアダプターがアプリに渡す
- アダプターがメッセージのやり取りをする
ヘキサゴナルアーキテクチャ日本語翻訳ページ http://blog.tai2.net/hexagonal_architexture.html
マイクロサービスのポイント
- 各サービスは独立、単一でデプロイと実行が可能
- 分割単位はビジネスの境界やビジネスの遂行能力で分割する（技術的なものではない）
- プロトコルはhttpでRESTfulのケースが多い
- 各サービスごとにスケーリングできる
Polyglot Persistence
- 各サービスごとに最適な言語とDBを組み合わせる
- 検索: elasticsearch
- ソーシャルデータ: Neo4J（グラフDB）
- ユーザーセッション: Redis
Amazonの例
- Amazonも昔はモノリシックなサービスだった
- チームの体制がTwo Pizza Team理論に即した体制に変化
- それによりチームの体制がマイクロサービスの文脈へ
- 開発チームは小さく、それぞれのチームが開発した単位でリリースできる
アプリケーションの実装パターン
Graceful Degradation
- 500エラーは返さない
- 一部にエラーがあっても全体の停止を起こさずその他の機能は有効に動くようにする
- 例えば、ECサイトのリコメンド機能がダメな場合でも、トップページにアクセスしてもページが表示されるようにする。おすすめ品が表示されなくても、全部表示されないよりマシ。
Fail Silently
- 外部向けには、エラーコードを返さない。
- 内部できちんとロギング、監視すること。
retry
- 失敗は一時的なものが多く、リトライすることで成功することが多いため、リトライする処理を入れる。
- 間隔の調整はフィボナッチ数列、exponetial back offを利用する。
curcuit breaker
Smooth internal traffic
マイクロサービスの考慮点
- 分散したコンポーネントを扱う難しさ
- レイテンシー
- トランザクションが複数のサービスをまたぐことがありえてしまう
- 西谷さん個人の考えでは、プロダクトが小さい場合はマイクロサービスのデメリットの方が目立つ
トランザクション
- 複数DBでデータが同期されている必要性
- 結果整合性の導入
- 状態変化に合わせてイベントを発行する
- イベントをsubscribeし、イベントドリブンに処理を行う
- 一時的なconsistencyの妥協
イベントソーシング
- 状態でなくイベントを追加するという考え方
- イベントのリプライにより現在の状態を導出できる
- スケールしやすい（キャッシュが楽）
- イベントドリブンでは、状態を変更しイベントを追加するが、これはイベント追加のワンアクションで済む
CQRS
- DDDの文脈で登場
- 更新処理と参照処理の分離
- 更新処理は正規化、クエリは非正規化の方がいいなど差異が大きいため
RESTfulAPI
ステートレスは他の店員になっても問題無し→スケーラビリティが高い
AWSでどうマイクロサービスを実現するか
- 満たすべき要件は自動化と自動化のためのAPI
- インフラは何でも良い
感想
アプリケーションの実装パターンやイベントソーシングという考え方など、知らないことが多く非常に勉強になりました。
昨日からAWS Summitに参加しマイクロサービスのセッションを拝聴していて、マイクロサービスの難しい点として「分散したコンポーネントを扱う難しさ」が共通して上がっていました。また、本セッションで挙げられたトランザクションやデータ同期も確かに悩ましい問題で、西谷さんが個人的には「プロダクトが小さい場合はマイクロサービスのデメリットの方が目立つ」とおっしゃっていた理由もよくわかる気がします。ビズリーチさんのマイクロサービスに関するインタビューでも竹添さんが同じようなことをおっしゃっていました。
開発のときのオーバヘッドや、インフラコストで見ると、短期的にはデメリットのほうが大きいと思っています。どこかで損益分岐点はあると思うんですが。とりあえずスモール仕立てでやってみようとか、成功するかまったくわから状況なら、モノリシックで作って、後から大きくなったタイミングでマイクロサービスにしてもいいのではないでしょうか。
非常にためになるお話をありがとうございました！
参考
html5experts.jp 12factor.net ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) AWS Summit Tokyo 2016 Developers Conference（DevCon） - アプリ開発・IoT の最新トレンドが集う2日間 - 2016年6月2～3日 グランドプリンスホテル新高輪 飛天会場にて開催
