【アーキテクチャ ディスカッション Vol.1】に行ってきました。

アーキテクチャ ディスカッション Vol.1

https://istyle.connpass.com/event/97862/

に行ってきたので、そのときのレポート

 

ディスカッション形式のメモです。
発言に対する発言を1つインデントするようにして書いています。

※正直、うまくまとめられている自信がないので、会話を追って雰囲気が伝われば幸いです。

 

ビジネスロジック層のモデリング

  • active record を使ったときのモデリングが難しい。どうモデリングをするかで分離の仕方が変わる。
    • DB を一回忘れるのはどうか?
    • DB のことは一旦忘れるけど、どこまでを考えるのかが重要になりそう。
    • それって DB を最初が存在している前提では?ソフトウェアの内部構造って、オブジェクトの意味やライフサイクル単位で作っていくと良いのでは?あまり、テーブルに引っ張られて考えるのはよくないかもしれない。
      • その分析ってどうやって始めます?
        • 業務フローから考えます。業務をプログラムに落とし込むにはどうしたらいいのかを考える。
        • この言葉はどういうカテゴリなんだろうとか。
          あまりプログラミングというか、サービス仕様だったりデータのカテゴリわけをする

          • この場合のデータってなんですか?
            • 仕様に出てくる言葉のこと。
            • モデリングっていう言葉の意味が幅広いので、焦点はここだよっていうのを考えるようにする。
            • エンジニアが使うことばっていうのはいろいろな意味があるので、その意味を付箋で貼ってみたりとかもする。
              部分部分でやっていかないといけない。業務の一番重要なところはどこなのかを聞いて、そこに焦点をあてるようにしている。

              • ドメインというのは、答えが出た時に、どういうことをやったんですか?
                • 僕らが行ったこととしては、経済活動という古くから使われているものをドメインとおくことにした。
                  入荷なのかなのかの単位を人それぞれだったが、少しずつリファクタリングすることで擦り合わせていった。
                  図書館アプリを練習で作ってみようとなった時に、
                  会社は貸し借りが大事なのか?いや、在庫管理が大事だ。となって、在庫管理をドメインとして初めて行った。

Clean Architecrue を採用した話

  • 最初始めたときは、どうしてもこの形にならなかった
    presenters を使わない人もいて、translater を使う人もいた。
    スクラップ  &  ビルドを繰り返して、最終的にはこの形になった。
    大事なのは UML 図だった。

    • entity はきっとトランザクション管理でもよいのだと思った。
      ヘキサゴナルアーキテクチャがきて、そのあとこの形になったと思っている。
      オニオンアーキテクチャはただ単にドメイン駆動設計のことを行っているだけなので、use case の部分。
      僕はこれ、浸透させるために教育させるのは無理だと思った。
      なので、ツールを作った。
      WEB のときは、 presenter のときはいらないと思った。
      非同期処理は contorller が返してくれたほうが都合がいいときが多い。
      なので、WEB の場合は presenter はいらないが、GUI ツールのときはいると思っ

      • 教育は諦めた的なことを言っていて、ツールを作ったという話があったが、
        こういう手順でやってねということをやると、考えずにやってしまう人が出てきそうだが、どう思うか?

        • ツール使った方が早くできるよ、というメリットを提示して納得してもらった。
          保守フェーズをやったことがないエンジニアって、伝わらないからつらい。運用する辛さが伝われば話も伝わる。
          そういう意味では、モノリシックで1000行ぐらいあるメソッドの保守とかしてもらったほうがいいかもですね笑(会場でも笑いが起こる)
  • presenter について最近本を読んでて思ったことがあるが、
    本では、presenter はテストしにくい部分とテストしやすい部分を分けましょう、という話が23章であった。
    その中では、 view はテストしにくいが、viewmodel まではまだテストできるという内容だった。
    プログラミング言語中で、日付オブジェクトというものを view に渡したときに
    文字列に変換しなければいけない。
    日付オブジェクトを文字列に変換するのが presenter
    その文字を活用するのが view という感じにしていたので、
    presenter は必要なのでは?と思った。

    • dto を使っていて、テストするので、そこは問題ではないと思った。
  • clean architecture に乗っ取ってるかを管理する CI ツール気になる。
    • それは取り組みをやっている。構文を解析してチェックするようにしている。
      java で gladle を使ってやっているが、導入も簡単なので良い。
      ドメインの依存すべき方向とは逆方向になっているときなど、そういうのはすぐに検知できる。

DB に入れるときに レポジトリって入れると思うが、何を引数に渡している?

  • DB の方は基本的にイベントを保存するようにしている。
    失敗談で、entity を渡すっていうようにしていたら、
    レポジトリの中で新しい entity が渡されたときに、古いものとの差分をとって DB にインサートとかしていたので、その管理がつらくてやめた。

    • 僕もentityというか集約をインサートしている。
      • それってentityとテーブルに差がない状態になる?
        • いや、差がある。
        • DDD のいいところが、イベントをインサートするとDBは肥大化するが、ドメインは綺麗に保てることができるのでそこがいいと思っている。

レポジトリにおいて、参照系と更新系で分けている人はいますか?

  • 参照系だとオーバーヘッドが大きいと思うが、参照系でもユースケース層もあったほうが便利だよねという面もあって、みなさんの事例を聞きたい。
    参照系と更新系を同じレポジトリで管理するか否か?ということ。

    • Clean Architecure の場合は、ユースケースがインターフェイスになるので、レポジトリ使わないパターンで行った。
      • レポジトリはそのまま経由させて、書くのは RDS を使って読むのは Elastic Search とかを使ったりもしている。
        • たしかに書くのは多くなる。DB の先って何年か後に違うのにしようという話が出てくるので、そういう風にしている。
        • 両方とも同じように扱いたいので、レイヤを挟まないようにしている。
          • 逆に、レイヤを分けるようにしている人いますか?
            • 挑戦はしている。ドメインを守りたいみたいな方向でそういう風にしている。
            • 読む先と書く先が違うからという理由があるが、
              キャッシュが落ちた場合って、DBに取りにいくと思うが
              そういう場合はインターフェイスは同じだが、中身は違うようにしている。

キャッシュって、みなさん(Clean Architectureの)図でいうとどこに入れていますか?

  • DB のところに入れている。
    ただ、ドメインをまたぐときに困る。

Clean Architecture って、人と会話するのが苦手な人にとっては苦痛かもしれない

  • 人と会話して、こっちの人は商品って言ってるけど、こっちでは違うことを言っていて、
    そこの分析をやるのが楽しい。
    逆にそこを分析してからでないとコードに落とし込めないと思う。

    • お金をもらって、人に本当に必要なものを作るためには、人と会話ができないといけない。

ドメイン駆動をやっていると、自分の言語がプログラムになってくるのでプログラムを英語で書くのが辛くなる。

  • 逆に日本語のローマ字で書くと良いと、結構読みやすくて良い。

Clean Architecture の本を読んで思ったが、実践に使うには大きなサービスでないとやりずらい。ただ、実際に手を動かさないと習得しずらい、みなさんはどのようにしていますか?

  • 教育を2週間、題材を用意してやってみた。
    すると、完璧に理解するのは難しくても、コピペすればなんとかできるという状態には持っていけた。
  • 個人的には、小さいサービスを作ってみて練習している。
    自分の中で鉄板のお題(RSSリーダーを作るみたいな)を作ってみるというのをやっている。

    • その時って実際に業務でやるときとのレベル感というのが出てきてしまうと思うが、
      どうやってその差分を埋めてますか?

      • 埋まらないですね。ただ、どうしても抑えておきたい部分(例えば例外ハンドリングの仕方とか)はやるようにしている。
  • うちの会社ではレビューで学んでもらうようにしてますね。小さい単位で業務を任せて、レビューして教えたりする。

Flux アーキテクチャって Clean Architecture に似てるって思った人います?

GUIを組んでるときに思ったんだが、形的に似ているなと思った。
そのとき思ったのが、サーバーを介さなければ同じ形になるのかな?と思った。
特に思った人がいないので、この話はやめます笑

ゲームアプリのエンジニアも Clean Architecture に興味あるらしいですよ。

  • ゲーム全体をそうするのはしんどいかもしれないが、一部分だけ Clean Architecture にしてテスト可能にするのは良いと思う。

みなさんどういった経緯で設計とかアーキテクチャに興味を持たれましたか?

  • 僕の場合は 13 年続くでかいサービスを一人で保守していて、そこでアーキテクチャが必要だと思うようになった。
  • 自分でクソコードを生み出して保守しきれなくなって、あるべき姿ってどんなんだろうと思ったのがきっかけ。
  • コアなモデルのほうに興味があったのが一つと、学生のときに設計やアーキテクチャの情報がたくさん入ってきたので、そこがきっかけ。
  • オブジェクト指向から始まって、すごい人が言ってるからいいものに違いないと思って勉強から入った。
  • DBに興味がもともとあった。データモデルが出発点になって、それがきっかけ。
  • 入社したときに、Android が世に出たときくらいだった。一番最初の Activity に何千行もあるアプリを保守しなければいけなくなった。
    そこをどうにかしなきゃねって思って、アーキテクトの考え方になって言った。保守しやすいアプリケーションを突き詰めたら、今に至った。
  • 炎上しているPJがあって、どうにかしてくれというふわっとしたオーダーがあった。
    そういうもののセオリーってテストを書いて始めていくのだが、どうせだからドメイン駆動設計(というのがあるらしいレベルだった)を突っ込んでみたのがきっかけ。
    炎上PJってもしかしたらチャンス(新しいことに取り組める)なのかなと思った。
  • 他者が作ったが放り出したものと同じものを作ってくれと言われた。
    それが、ループが17段あったりもした。
    そういう過酷な状況の中で生き残るためには設計が必要だと思った。
  • 会社が、一人で作って一人で運用している人が多く、アーキテクチャを知っていないと自爆してしまうことがあるので、それがきっかけになった。

分析系の処理を書く(マイクロn秒)ときには、Clean Architecture は採用しないことが多い。

  • なぜかというと面倒臭いから。
    速く返さないといけないときとかは一つのファイルにたくさん書いたりする。

    • それはそれでいいと思う。
      そのソフトウェアが求められている関心事による気がする。
      人が運用する上での複雑性を解決するのが Clean Architecture だったりするし、
      速く返さないといけないとかだと技術的なアプローチが必要になるので、そのときどきにあったアプローチが必要
      Clean Arhitecture は万能薬ではないので、適材適所なアプローチが必要になってくる。

本の内容に関して

「本当の重複」と「偶然の重複」があって、

  • 重複を排除すれば無条件で良いと思っている人がいるが、そこについて書かれているのが嬉しかった。
    • このコードを重複させるべきかどうかという点を考えた時に、
      テストできるコードが設計ができるコードというわけではないと言われたりもした。

組織の形態がアプリケーションに反映されてしまうという法則がある。

  • 組織の形態はなかなか変わらないが、アーキテクチャはよりよいものにしたいと思うときがあるが、みなさんどうしていますか?
    • うちは microservice を採用していて、新しく入った人にはローテーションして多くを触ってもらうようにしている。
      そういう風に知識を蓄えてもらうようにしている。
  • 組織変えなきゃなと思いながらコードを書いたりもしている。
  • 何かサービスを作ろうとなったときに、新しく部署が生まれてそこで作るような文化になっている。
  • スクラッチで作られるサービスがたくさんあるので、横軸で共通で使えるようなライブラリとかプラットフォームがあったらいいと思うが、
    いまのところ組織と同じ形になってしまっている。
  • アーキテクチャ設計と組織設計って同じだと思っていて、組織設計やる気持ちがないとアーキテクチャ設計できないと思う。
    組織設計はマネージャーがやるというマインドだとできないと思う。
  • 結論、組織設計から逃げない。

【システムを構築するときに気をつける10のこと】に行ってきました

【サポーターズ勉強会】システムを構築するときに気をつける10のこと

https://supporterzcolab.com/event/233/

に行ってきたので、その時のレポート

資料

基本的に、このスライドに書かれていることをなぞって講演していただいたので

このスライドをみればだいたいイベントの内容が分かります。

ただ、口頭で説明のあった箇所などはメモをとっていたので

下記に記載します。

まえおき前提

web業界において、スピード重視でサービスリリースするような開発

アジャイル開発などを対象に今回の講演をします。

登壇者の方がよく思うことが、

サーバーサイドエンジニアから受ける質問として

「この機能作りたいんですけど気をつけることありますか?」

と聞かれることがあるのだが、気をつけることはいっぱいある。

だが、書籍とかで気をつけるべきことの情報は見つけにくい。

それで、今回ざっくり説明をしていただける。

安定稼働にはコストとリソースがかかる

設計とかで、結構時間がかかる。

オンプレで動いてたものをクラウドで動かすとかだと、

どのくらいの費用がかかるのか、どういう設計にするのが良いのかが検証してみないとわからない。

例えば、クラウド環境で冗長化するとして、

マシンを1台で動かしてたものを2台にするとかだったら、2倍料金がかかる。

1台が死んだら2台目に切り替わるという仕組み作りの検証もしておかないといけない。

運用体制コスト

誰が通知を受けて、、誰がエスカレーションして誰が対応するのか

とかとかのマニュアルが必要。

ディザスタリカバリを考え、日頃から訓練する。

オペミスとかでデータが消失したときの対策

これは結構難しい。

設計はしたけど、日頃訓練しておかないと

いざ障害が起こったときに、うまく動けないことがある。

擬似的に障害発生させて訓練しよう

システムが落ちたという報告を誰が誰にエスカレーションしないといけないのかを決めておく

例えば、上司に報告して、上司はお客さんに報告するとか。

モニタリングのメトリクスは細かく取る

こういうのを細かくとっておくと、

障害が発生したときとか、スケールするときに情報になる。

ただし、メトリクスをとりすぎると逆にマシン負荷になるので注意が必要

代表的なメトリクスはグラフにしたりしておく

また、そのメトリクスの意味を理解しておく

query/sec というメトリクスってなんのクエリなんだっけ?」とか。

システム全体がスケールできる

ネットワークのスループット

例えばデータセンターだったら、外から入って行くるのが1本だったら、それに耐えられるのかとか。

外部連携

例えばBIツールを使っているときも、外との連携でスケールできるんだっけとか。

設計/選定した技術には責任を持つ

使ったけどちょっと違ったかなというときは

ちゃんと自分で負債を返していかないといけない。

技術選定が間違っていたとかいうこともあるが

それをちゃんと返して行こう

そのためにも、採用した技術には一番詳しくなっておこう。

仕様やデータ構造の変更は必ず発生する

仕様とか技術は変わっていくので

変わってもいいように設計を考えておきましょう。

データの保管場所は塾考する

例えば、クラウドからオンプレに持って行きたいとなったときに

データ量が多いと、転送時間に時間がすごくかかるので気をつけないといけない。

データレイクというのが最近注目されている

データレイクとは、1箇所に全てのデータを集めて使えるようにしましょうという考え方。

セキュリティ対策は必要だが、コストと時間がかかる

権限管理はすごい大変

ここはちゃんと設計しておかないと行けない。

権限の設計が必要

 → しかも、変更が入るので、柔軟な設計が必要

誰が管理して、だれが付与して・・・

転職とか退職とか、人の入れ替わりがあって、権限の管理が大変

クラウドを信頼しすぎない

クラウドはだいぶ安定・安心できるが、100%の安定では決してない。

EC2の場合、メンテナンスのために強制的にシャットダウンされることがある。

だが、EC2の中でvmが動いていて、vmの中のメモリでアプリケーションが動いていて、

シャットダウンさせるには、メモリにのっているデータを退避させないといけないとかの状況の場合もある。

だが、シャットダウン日は10日後に迫っていてつらい。。みたいな状況もある。

謎のサービスレベルの低下

AWSに質問した。

回答は、他で使われているインスタンスの負荷で、それに引っ張られてますとかの回答がきた。

結局、言いたかったこと

優先順位を決めよう

セキュリティが重要だったらそれからやろう。

スケールが大事だったらそれからやろう。

全部やれるにこしたことはないが、時間もないので。

Q & A

Q.どんなメトリクスで区切るとかコツはある?

A.僕(登壇者の方)の場合は低レイテンシーが求められているので、

 1msec, 4msec, 10msec, …. とかで返したクエリとかでメトリクスを切っている

 そのときのメモリの使用量とかを分析できるので、目的別でメトリクスを区切るようにしている。

 

Q. おすすめのメトリクスツールは?導入が簡単とか。

A. saasサービス

   New Relicとか。

   Datadogをリソースの管理で使っている。

   Datadogは楽。

   どちらも外部サービスなんで、アラート飛んできたらどこにいても見れるとかのメリットはある

   ただし、セキュリティに厳しい会社だとそれができないかも

   zabbixとかも、サポートが手厚い。

   

Q. 外部のメトリクスサービスを使うのではなく、逆に自分たちで作らないといけないときの条件は?

A. KVSとか、高速にクエリを処理したいときとか。

 AirSpace?というKVSと使っているがDatadogとかだと対応していなので

 分析用のシェルを自分でつくって、それをDatadogに投げるとかのことは自分でしないといけない。