2024-01-12

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へのリクエストがなくなったマイクロサービスから順次、サイドカーを無くすという選択がとれるので、段階的な縮退ができる。

結論

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

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

2023-12-14

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"

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

2023-12-12

JTCでのソフトウェア開発のギャップ

概要

メガベンチャーからJTC (Japanese Traditional Company)に入ってギャップを感じた、ソフトウェア開発プロセスについてまとめる

※ JTCの全てがこういう状況ではないことは百も承知です ※ これから内製化をしていこうというフェーズのJTC(製造・小売業)が題材です

異常に多い会議
中途半端に関わるプロジェクトが多い
1on1の目的がよくわからない
承認プロセスが無駄に長い
複雑なリリース承認文化
圧倒的メール文化
情報の不透明さ
包括的なドキュメントはある、ただしどれが正しいのかは属人化されている
コードを書くよりエクセルをいじる時間が長い
結局はベンダーがやりやすいような開発プロセス

異常に多い会議

なにしろ会議が多い。開発をしようにも、半日が会議で埋まることもざらにある。その会議が午後にまとまってるのであればまだ良いが、中途半端に散らかっているので、まとまって開発する時間が取りづらい。時間を動かそうにも、関係者(本当に関係者なのかはよくわからない人)が多く、調整コストが高いため諦めてしまう

中途半端に関わるプロジェクトが多い

1つめの原因でもあるが、小さいプロジェクトなどがいくつも走ることがあり、どれに集中してるのかよくわからないことが多い。オブザーバーとして呼ばれたり、テック的な意見を求められて呼ばれることも多く、結局プログラマーがエンジニアリングする時間が取りづらくなってしまう。また、エンジニア以外の人も色々やっているため、結局どれも中途半端になることが多い

1on1の目的がよくわからない

とりあえず1on1入れますみたいなのが多い。(あくまでも自分だけかも) 1on1やらないのは良くないが、1on1の目的/意義/やり方を知らずして、とりあえず上長だから入れるとか、チームメンバー同士で交流頻度を上げて欲しいから入れるみたいなのが多く、個々人の成長につながる1on1は極めて稀である

承認プロセスが無駄に長い

無駄に階層構造とセクショナリズムが強いため、1つのプロジェクトを進めるにも調整コストが異常に高い。また、大企業特有のプロセスに対してガバナンスを敷きたがるため、とりあえずいろんな人に説明して承認を得るみたいなことが発生しがちである。

複雑なリリース手順

リリースをするのにも、毎回リリースの手順や切り戻し方法、対応時間を分単位で示したものをエクセルにまとめて共有する必要があり、それを御前会議みたいなところで承認を得る必要がある。また、ブランチ運用もかなり複雑で、リリースまでに複数のブランチにマージする必要があったり、リリースまでにかなり時間を要することがある。

圧倒的メール文化

SlackやTeamsが導入されてはいるものの、情報伝達は基本的にメールが中心。

情報の不透明さ・包括的なドキュメントはある、ただしどれが正しいのかは属人化されている

どこに何があるのかわからないが、一応ドキュメントはあることにはある。ただし、エクセルやパワポがそのままファイルサーバーに格納されて、ぱっと見どれが正しいのかよくわからない状態。ただ、社内に一応どれが正しいのか知ってる人はいるので、その人を探し出せれば情報に辿り着ける。

コードを書くよりエクセルをいじる時間が長い

資料作成の時間が圧倒的に多い。内製化を目指してるといいつつも、まだまだコードを書く作業はベンダーに投げるものという文化が染み付いており、何をやるにもとりあえずエクセルやパワポで提案資料を作るということが多い。

結局はベンダーがやりやすいような開発プロセス

上記の背景もあり、結局はベンダー依存が強く、エンジニアが入ってプロセスを変えようにも、パワー的にベンダーの方が強く、ベンダーが慣れ親しんだプロセスに固執しがちというのが実態である

まとめ

よくある内製化という言葉が、エンジニアから見た時の内製化と非エンジニアから見た時の内製化は意味が異なる

仮にこれから事業会社で内製化エンジニアを募集してるところに応募する人がいたら、まずは内製化エンジニアのメンバーとベンダーの構成比を確認することはマスト。その中で自分が期待されてる役割を聞いたり、内製化のマイルストーンを丁寧に擦り合わせることをお勧めする。

2023-12-09

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

背景

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

結論

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

よくある話

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

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

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

どうするか

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

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

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

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

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

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

まとめ

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

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

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

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

2023-12-07

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

背景

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

結論

タイトルにあるとおり。

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

きっかけ

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

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

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

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

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

解決策

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

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

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

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

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

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

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

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

だと思う。

まとめ

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

2023-12-01

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

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

背景

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

本題

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

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

スクラムとは

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

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

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

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

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

agilemanifesto.org

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

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

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

どうしたらいいか

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

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

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

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

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

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

結論

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

2023-10-19

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になげて集約させるが、素の検索結果をコンソールから確認することも可能。

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