yu-tarrrrの日記

完全に個人の趣味でその時々書きたいことを書く

kubernetess環境でmicroserviceとsidecarを活用する

背景

1つのマイクロサービスを開発する中で、レガシー環境のCMSにアクセスしてコンテンツを取得する要件が出てきた。

その際に、CMSのresponse形式を指定できず、アプリ側でHTMLをパースしてjsonにする処理が必要になり、その責務をどこに持たせるか？という話

理想

そもそも、理想としてはCMS側がjson形式で返せるように改修するのが理想。

とはいえ、リプレイスが決まっており、かつレガシー環境につき開発コストをそこにかけるのが妥当とは思えないので、他の選択肢を検討している。

パターン① 各MS側に処理を持たせる

愚直に考えたら、これがまず思いつくと思う。

各MS側でCMSにリクエストしたのち、レスポンスの中身をパースする処理を行う。その後、業務ロジックなどを経て、APIレスポンスとして、クライアントに返却するというもの。

至ってシンプルではあるが、下の図のようにAPIが複数存在する場合、MSの数だけ処理が散らばることになり、本当に良いのか疑問が残る。

また、CMSに対してクライアントの責務なのか？というのが、個人的に疑問が残った。

パターン② 共通処理として切り出し、汎用的なサービスを作る

マイクロサービスとして、Parse APIのようなものを作るというもの。

レスポンスヘッダーをみてhtmlだったら、そのままParse APIにMS側からリクエストを送るというもの。

あくまで、これはCMSのリプレイスが終わったら捨てる前提のAPIという建て付けにはなる。

メリットとしては、parseするという共通処理を1つのAPIに集約させることができる。

デメリットとしては、Parse APIが単一障害点になる可能性があり、割と影響度もでかい。また、通信も発生するので、多少のオーバーヘッドが発生する。

パターン③ 共通処理をサイドカーとしてデプロイする

今回の推しはこれ。

汎用的な処理を共通のライブラリとして配布することができ、かつ、単一障害点になることを防げるというもの。

サイドカーの場合、メインのコンテナとライフサイクルを共にするので、どちらかだけ死ぬみたいなケースは防げるし、仮にparseできないとなったときに、その影響度はマイクロサービス単位で閉じることができる。

また、pod内通信になるので、マイクロサービス間の通信よりもオーバーヘッドが少ない。

さらに、今回のリプレイスという文脈においては、マイクロサービスにしてしまうと、全部のリプレイスが終わるまでParse APIを残す必要があるが、sidecarにしておけば、レガシーCMSへのリクエストがなくなったマイクロサービスから順次、サイドカーを無くすという選択がとれるので、段階的な縮退ができる。

結論

今回は大人の事情がありパターン①を選択したが、いろんな観点からとりうる選択肢を比較してみるのが良さそう。

思考停止でマイクロサービスのではなく、サイドカーという選択肢も持っておくことで、サービス(ドメイン)まで大きくないけど、汎用的なものを共有してメンテナンスしていきたいというユースケースに応えられると思うので、積極的に活用していきたい。

OrbStackでは .docker/config.json を読みこまない

背景

docker でproxyサーバーを利用する時、以下のファイルを作って設定してました。

{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://",
     "httpsProxy": "http://",
     "noProxy": "*.test.example.com,.example2.com,127.0.0.0"
   }
 }
}

matsuand.github.io

コンテナーの新規生成時や起動時には、コンテナー内に環境変数が自動的に生成されて設定が効いていたのですが、そもそも、Docker CLI clientのみでしかサポートされてないやり方とのことだったので、Orbstackのnetwork設定から追加する。

github.com

やり方

docs.orbstack.dev

$ orb config set network_proxy http://example.com

これだけ。設定は確認できる

$ orb config show
network_proxy: http://127.0.0.0:8080

もしくは、コンテナの中で直接環境変数に入れてしまうのが良いかもしれない。

--env HTTP_PROXY="http://127.0.0.0:8080"

とはいえ、都度やるのはちょっと面倒だから もう少し良いやり方を模索したい。

人は学びを得るときに心を開く

背景

今までなんとなくで構築してきた信頼関係について、転職を機に考え直してみた。

結論

人は学びを得たときに心を開く。その積み重ね

よくある話

転職などをした直後、チームを異動した直後など、新たに来た人は、今まではこうだったとか、こっちの方が良いと思いますと押し付けがち。

でも、それを伝えられた側としては、今までのやり方だって満足していたし、急に来たやつがなんだ？と思ってしまうこともあるであろう。

そうなると、人はガードが固くなり、聞く耳を持たなくなってしまう

どうするか

この情報が役に立つだろう、これが必要だろう、と一方的に押し付けるのではなく、まずは相手のやり方を理解する努力をする。

このとき、観察や傾聴が役に立つ。

ただ、観察や傾聴してるだけではずっとお客様のままなので、聞いてる内容に対して自分の意見やスタンスを用意しておく。

あくまで用意するだけで、自分から発信することはしないでおく。

そして、自分の意見やスタンスを求められるタイミングを待ち、そのときが来たタイミングできちんと発信して、共感を得る。その繰り返し。

そうすると、人はこの人はこういう考えなのか、と理解して、意見を求められるときに消極的だったものが積極的になっていく。

まとめ

環境が変わった直後は特に結果を出そうと焦ってはいけない。

まずは相手を理解して、相手のやり方に合わせて柔軟に対応していく。

ただし、自分のスタンスは変える必要はない。

リスペクトを持って協働して、より良いものを目指していければ良い。

当たり前のことを当たり前にやる組織

背景

開発生産性が謳われる昨今、どんな組織が強いのか考えてみた

結論

タイトルにあるとおり。

当たり前のことを当たり前にやり続けられる組織が強い。

きっかけ

ソフトウェア会社と事業会社、何が大きく違うのかと考えた際に、ソフトウェア会社と事業会社では当たり前と考えるラインが全然違う

たとえば、テストに関する考え方であれば、自動テストをリリース前に必ず実行していて、pipelineで通らない限りリリースできないようになってるとか。

たとえば、無駄なエビデンスを拡充させるより、きちんと動く環境をメンテナンスし続けるとか。

列挙したらいくらでも挙げられるが、当たり前と考えるラインが大きく異なる。

かつ、その当たり前を守る強度も大きく異なる

解決策

レガシーな環境が一気にモダンな環境の取り組み事例を全部導入すると破綻するし、それを運用する体力がない。

なので、理想を知りつつも、現実とのギャップを理解して、マイルストーンをきちんと設定していく。

当たり前と思えるラインをちょっとずつ引き上げていくというイメージ。

例えば、最初はテストのカバレッジを意識するとかからでも良いと思う。そこから、カバレッジだけでなくてテストピラミッドを意識してみるだとか、効率の良いテストとは？を考えてみるだとか、ちょっとずつステップアップしていくイメージ

なので、重要なのは3つ。

現段階のレベルでの当たり前をまずは継続すること

当たり前を継続できるようになったら、当たり前のレベルを引き上げること

そのためには、理想の状態を知り続けること

だと思う。

まとめ

当たり前のことしか書いてないけど、当たり前にこういうことをやっていきたい

たしかにスクラムはアジャイルではあるが、スクラムをやってるからといってアジャイルであるとは限らない

タイトルが周りくどいですが、言いたいことを全部詰めてみました。

背景

  • SWEとして働いてると、Bizメンバーが使う「アジャイル」とエンジニアの使う「アジャイル」が異なる瞬間があることに気づいた
  • ソフトウェア会社と事業会社においても、アジャイルへの理解が異なると感じる
  • なんちゃってスクラムマスターみたいな人が意外と多いなと思う

本題

タイトルの通り、スクラムはたしかにアジャイルの一つの手法である。

だからと言って、スクラムをやってるから我々はアジャイルだ！といってる人たちを見かけると強く違和感を感じるケースがある。

スクラムとは

よくあるスクラムでは、1-2週間でスプリントを切り、朝会で作業状態の確認をし、ふりかえりをして、次のスプリント計画をしましょう。みたいな説明がされている。

たしかにそれは正解だし、「スクラムを実践する」という意味では正解なのかもしれない。

ただ、その中での実態を見てみると、実はスプリントの中でWF(ウォーターフォール)のプロセスを順番に確認してるだけで、ただチェックポイントを設けてるのと一緒じゃんと思うことがちょこちょこある。

アジャイルとは考え方である

アジャイルと言って、まず参考にすべきは「アジャイルソフトウェア開発宣言」であろう

agilemanifesto.org

これを読んだことなくして、アジャイルやってますとかいってる人は、偽物である。

この宣言や原則を読むと、具体的な手法というよりかは考え方の部分に多く言及されているのがよくわかる。

なので、アジャイル = スクラム、すなわち「How」の部分だけなぞって満足してる時点でアジャイルではないと考える。

どうしたらいいか

「How」だけでもだめだし、「Why」だけでも足りない。

両方を常に追求すべきであり、両方に対する理解のアップデートをし続けるべき。

スクラムから導入するのは、たしかに導入しやすいから良いと思う。

ただ、導入しっぱなしで終わるのではなく、プラクティスやプロセスの背後にある原理原則を理解するべき。

アジャイルについて向き合い続けるというのは大事。技術と同じで入れたらおしまいというのではなく。

そして、自分たちがやっている業務などにおいて、アジャイル的にはどうしたらより良くなるのか？というのを考え続けるべきである。

結論

変化を抱擁せよってことだと思う

Amazon Kendraの考察

Amazon Kendraとは

aws.amazon.com

エンタープライズ検索エンジン なんですよね

勘違いしてたんですけど、単純なベクトル検索エンジンとは全く違うという

ベクトル検索エンジンではあるのですが、その強みは以下の通りである

  • 豊富なコネクタが用意されており、複数のデータリソースが存在する場合に強みを発揮する
  • Kendra自体に検索UIが用意されており、自然言語での検索が可能である
  • 多様なファイル形式をサポートしており、いい感じに取り込める
  • 単純なキーワード検索ではなく、コンテキストを理解した検索が可能

豊富なコネクタ

aws.amazon.com

ここにある通り、Jira, Confluence, Microsoft製品などなど、さまざまなものが用意されており、API keyの払い出しさえできれば、UIから設定が可能。

こういうものがないと、自前でS3にアップロードするためにlambdaをかいて、Batch実行するみたいな設定をしないといけないので、なんとも便利。

Kendra 検索UI

docs.aws.amazon.com

AWS Consoleから検索可能。chatbotなどを作るときは、API経由で問い合わせて、結果をAIになげて集約させるが、素の検索結果をコンソールから確認することも可能。

サポートしてるファイル形式

docs.aws.amazon.com

ここにある通り、だいたいの形式のデータを取り込むことが可能。 注意したいのが、形式によって構造化データになるのか、非構造化データになるのかが異なるので理解した上で使えると良さそう。 PDFなども読み込めるので、自前でOCRなどを経由させる必要がないので、ありがたい。

ベクトル検索

www.elastic.co

キーワード検索だと、構造化データであれば精度がでるが、非構造化データの場合は精度が出にくい。 そこで、非構造化データから意味やコンテキストを取り込み、ベクトルとして検索インデックスに取り込み、近似近傍アルゴリズムを使用して検索することで、より精度の高い結果を導き出す。

Pricing

Amazon Kendra の料金 - アマゾン ウェブ サービス

月額15万 ~ という感じではあるが、フルマネージドである点やこれだけのサポート充実っぷりをみると、むしろ安いのでは？感がある。 エンタープライズ検索エンジンの名の通り、値段が高い分、充実したサポートは受けられて、昨今話題の生成系AIを用いたchatbot開発などへの障壁を下げるのに一役買ってくれそうな印象

アジャイルマニフェストの一部分について考えてみた

はじめに

アジャイルマニフェストとは

  • アジャイルソフトウェア開発宣言の方が聞き馴染みがあるかもしれないが、今から20年くらい前にpublishされたもの
  • 下の文章のこと
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

引用元

今回考えたこと

  • たまに読み返していて、「包括的なドキュメントよりも動くソフトウェアを」と「契約交渉よりも顧客との協調を」と「計画に従うことよりも変化への対応を」については、ふむふむって感じで前から読んでたのですが、「プロセスやツールよりも個人と対話を」についてはなんか腹落ち感がなかった
  • ですが、今回は「プロセスやツールよりも個人と対話を」について、なんか理解できたので言語化していこうと思った

プロセスやツールよりも個人と対話を

  • 本来は「Individuals and interactions over processes and tools」というのが原文
  • もやもやしてたポイントが、「プロセスとツール」が「個人と対話」の対比構造？比較対象？になっていることが、イマイチ理解できずにいた

「プロセスやツールよりも個人と対話を」の裏側にありそうなこと

  • これを紐解いていくなかで、アジャイルとウォーターフォールを比較するとわかりやすいと思った
  • ウォーターフォールは、なるべく属人性を排除する。だから、マニュアル化するのであって、テスト項目書を作って誰がテストしても同じ結果が得られるようにするし、誰が使っても同じようにバグが見つかるようなツールを求める(これは言いすぎかも)
  • アジャイルは、人の違いに理解をおく。あなたと私は違いますよね、だから対話をして理解をしていきましょうという考え方。なので、全員同席して色んな人が対話をするようにしている。
  • 例を用いると、ウォーターフォールだったらバグがあったときに、それを誰でもが検知できるような仕組みを考えると思う。(たぶん)
  • アジャイルだったら、仕様についてテストエンジニアと洗い出すとか、コミュニケーションで防げたよねみたいな対話をすると思う(してる)
  • なので、アジャイルとウォーターフォールは根底のところで、プロジェクトにおける人への考え方が違うんだろうなーと思い、そこが起因してるんじゃなかろうかというのが今回の仮説
  • 炎上してるプロジェクトに人を投入するか否か、というのも一定上記の違いからきてるんだと思う。
  • これはどっちが良いとかではなく、あくまでも考え方の違いなんだろう

一方で

  • アジャイルが属人性を排除してないかというと、それは違う
  • ペアプロで知識を伝播してるし、コードの共同所有みたいな考え方がある
  • なので、両者ともに属人性を排除しようとはしていて、属人性を排除するためのアプローチの仕方が違うだけって考えるのが一番しっくりくる

要約すると

  • 「プロセスやツールよりも個人と対話を」については、属人性を排除するためのアプローチの仕方がアジャイルとウォーターフォールでは違うんだろうなと読んでいて思った
  • 人の違いに注目して、対話を繰り返すことで知識やノウハウの伝播をしていくアジャイルに対して、人という要素をなるべく除外して誰がやっても同じような結果を得られるような仕組みやプロセスを構築するウォーターフォールという考え方の違いなんだと理解した。

おしまい