コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『すえなみチャンス忘年会2019 』に行ってきたよメモ

行ってきたメモ

すえなみチャンス忘年会2019 本編 - connpassにいってきたのメモです。

各発表の感想

※資料スライドは見つけたら貼ります。

美しさでシステムを導く 数理的システム設計 -アレグザンダーと15の幾何学的特性-

speakerdeck.com

感想

  • 重力など物理法則レベルで普遍的なものに合わせて設計を考えることによって初手の設計の手戻りを下げることができるのではないかというアプローチ。
  • 出典としてアレグザンダーや美しさの話を使っており、異なるジャンルの知識の水平展開に関してのアプローチになるほどとうなずくばかりだった。
  • 現在ご自身のプロジェクトで試しているそうなので、そこでの知見もぜひ聞いてみたい。

関連リンク

チームリーディング フロントエンドコンポーネント分割の指針

感想

  • ゲームのUIでは当たり前のコンポーネントの考え方を適用するためにどう考えて、どうやってきたかの資料
  • この範囲はサーバーサイドエンジニアが兼業でやるため、ここまで突っ込んでできないのが実情だが、それだとしてもどうあるべきかのチーム運用論まで含めた広範囲のお話だった。
  • エンジニアに限る話ではないが、リーディングするものとして五十六メソッドは大切にしていきたい

関連リンク

ドメインサービスと参照透過性

感想

  • 実際のプロダクトで出会った困ったことに関してのスライド
  • 主たる開発がRailsの私はあまりモック地獄にあったことないのですが、PHPでBear.Sundayを使っているときはモックまみれになったので感覚はわかる、というレベルで聞いてました。
  • 密結合バリバリだとここらへんに思いをはせることがないので、実際やっていきをしていくとここらへんは避けられない気がするので、それこそ五十六メソッドでちゃんと背中を見せたりしないと行けない部分なのかもなと感じた

関連リンク

新鮮 GraphQL の React 焼き〜すえなみソースを添えて〜

スライドはなさそう

感想

  • GraphQLに関してスライドとライブコーディングをしながら説明していく話
  • GraphQL実装するのはこんな感じという話とそれのときに困る話などを実装しながら説明してくれた
  • サーバー側のプラグインがある言語はクライアント側がなかったり、逆のパターンがあるらしい、という知見を得る。

関連リンク

マイクロサービスに関するディスカッション

パネラーの方

座談会メモ

テーマは「マイクロサービス」だったので、トピックごとに書いていきます。

分散システムやチームを分けて成功したこと、失敗したこと

以下のような意見が出た

  • プロセスとしてはうまく行ったけど、チームとしてバチッとはまったことはない
  • システム分割だけの話で、チーム分割をやったことがない
  • 中規模レベルのチームまではやるべきではないと考えている
  • 物によっては外のサービス(SaaS)を使うのもいいのではないか

マイクロサービスの場合、DB共有はアンチパターンだと思うのですが共有したいデータがある場合にどうしていますでしょうか？

  • DBは各サービスごとにわけたい、モノリシックだと影響範囲を分けたいので、DBも分ける。
  • ビジネス駆動で分ける、技術駆動ではわけるべき。
  • DB共有は基本的にはやらない

皆さんの扱ってるシステムのリリース頻度やコード変更からリリースまでのリードタイムはどのくらいでしょうか？

下記のようなコメントが出た。

  • リリースは週1回、月に2回。
  • 社内向けツールなので、ITがすごく強い人が使うわけではなく、一般的なビジネスマンが使うツール。リリース頻度は頻繁で短め
  • 週に何回もリリースしている、ロールバックもやっている。デプロイ単位を考えて分けるべき。 モジュール単位で切り分けないとダメ。いちいち確認を取る必要がでてきてしまう。

サービスごとに異なる言語を使うのはアンチパターンだと思うのですが、異なる言語を採用した経験や、サービス間の言語的な多様性が負債になった経験はありませんか？

  • マイクロサービス言語も揃えておかないと、ビジネスとして使えない。言語違ってもいいよねという始まりだったハズなのに、言語揃えたほうがいいよねという雰囲気になっている。
  • ただ多様性に張ったほうがいいので言語を変える事自体は考えかた次第
  • やりたいからというので採用するのではなく、ちゃんとやるひとが教えるといい。
  • 要件に応じて言語を変える、エンジニアに自治権を与える。 コントロール権がないとやる気がさがっていく。 彼らのコンテキストの中で、選択したりコントロールできるほうがいい 自治権与えて、統制ができるといいのではないかという考え方。

マイクロサービスはまさに「機能で決定されたアーキテクチャ」です。ビジネスが変わったときの変更が困難に感じますが、そこらへん如何でしょうか？

  • 変わったら作り直せばいい、汎用的で抽象的な機能であればマイクロサービスにいいし、SaaSを使ったらいい。SaaSは競争があり、一番抽象化されたものなのでそれを使うといい
  • ユースケースを分解していくと、部品が出てくる その部品が機能Aに対応しているという作り 機能Bにも対応できますみたいな考え方もできる。
  • 普遍性と可変性の話があって、そこを分離して設計していこうという考え方、変化する部分と変化しない部分を考える。（ドメインとか境界づけられたコンテキスト）

境界のひきかたを間違えた、境界を失敗した場合

会場から意見が出た

  • システムの金額規模が大きい話で、早い段階でやり直した話がある。作るものがプラットフォームだったのでステークホルダーごとに分析を分けた。しかし現実的に流行り廃りの高いビジネス領域だと、ステークホルダーはいなくなったり、認識外のステークホルダーが出てくる。既存のステークホルダーの強さの想定ができない。
  • もともとマイクロサービスだったんだが、全社的な戦略変更があって、メンバーが一気に変わった。 新しく来たメンバーはシステムが触れなく、リプレースをするなどした。
  • 他のSaaSが出てきたので、自前のサービスをシュリンクさせていくことをやっていた。基本的なシステムをすべてリプレースし、自前のサービスを潰しに行った。その過程で暗黙的な知見がドキュメント化されていなかったものが、新たにあがったので、可視化できた。

マイクロサービスだとテスト（E2E的なテスト、QA的な工程）が環境を用意する面も含めて難しいと思っているんですがいかがでしょうか？

  • ユニットテストなどはある程度できるが、稼働率計算をどうすればいいのかは解を持っていない。切り方はどう考えるかが難しい。
  • 最近はk8s、ローカルでやるときは大変。ローカルのクラスタを立ち上げるのキツイ。結合確認を最終的にやらなければ行けない。
  • 不変条件、防御的プログラミングを徹底している。間違えた使い方をするとコンパイルできない。 契約例外で落とす
  • 型レベルでやっているからテストをしてないというのはある。型レベルの強い表明にテストを減らすことができる。
  • そもそもテストが難しくなっていたら、そもそも失敗。環境の再現が難しい、本番で以下にテストするかを考えているか、Trafficも含めてテストするか、本番でいかにテストするかを考える。
  • 考え方としてカナリアリリースなど、いきなり出さないという考え方をやることも大事。

感想

  • マイクロサービスを現実的にやってきた人たちや、立ち向かってきた現場の意見が凝縮されてて良かった。
  • テストはやっぱり難しいので、ある程度固い言語でやるほうがスムーズなんだろうな…という気持ちになるなど

全体を通しての感想

  • 全員が違う話でバラエティに富んでおり、きょんさんのアーキテクチャの話は発想の切り口含めて学びが多かった。
  • 最後の座談会はメモから起こしたが読み直してもそうだよな…という気持ちになることが多かった。
  • 自分自身も現場でわたわたしながらマイクロサービスやらなんやらやってるので知見をPublicな形で整形して出して行きたいな…