組織規模に応じたPlatform Engineeringの実践

皆さんこんにちは
株式会社箱物のShigaと申します
本日は本セッションにお越し下さりありがとうございます
本セッションの組織希望に応じたプラットフォームエンジングの実践ということで
早速お話をしていきたいと思います
よろしくお願いいたします
まず最初に目次になります
本セッションはこのような内容になっております
最初にイントロダクションということで
簡単に自己紹介や本セッションの概要についてご紹介させてください
次にですね
本当にすごく簡単にプラットフォームエンジングってこういうものですよね
というのもスライド1枚しか用意してないんですけど
そちらについて説明させていただきます
次にですね
最後に本セッションの本題である組織希望に応じた
プラットフォームエンジングの実践ということで
これまでの弊社での取り組みの実例や
現在進行中の実例2つについてお話しさせていただきます
もっと細かいフェーズでお話ししたかったんですけど
25分だと2事例が限界でしたすいません
まずイントロダクションになります
最初に私自己紹介させてください
改めてになるんですけども
シガーと申します
マコタスというニックネームで活動しております
株式会社ハコモノに所属しておりまして
2022年8月から所属しています
プラットフォーム部の所属になります
XとGitHubはこういったアカウントで活動しているので
よかったらフォローしてください
本セッションの内容になります
弊社のプラットフォームチームの取り組みですね
成果や失敗
成功失敗についてお話しします
ちょっと時間の関係上
技術の話は少しのみになる予定です
もし技術の詳細をもっと聞きたいという方は
スライドの資料に
技術ブログなどへのリンクがある組織の皆様や
これからKubernetesの採用を検討している組織に向けての
お話を思いする予定です
限られたリソースの中で
プラットフォームエンジニングをどうやろうか
みたいなフェーズの方に
参考になるようなお話を目指して
構成しております
弊社の事例の話から
自組織の導入の場合はどうなんだろうという
検討の材料や
気づけられるような
そんなお話ができたらなと考えております
次にですね
プラットフォームエンジニアリングについて
簡単に
すごく簡単に認識の合わせをしたいと思っております
ちょっとスライドが一枚なので
語弊があったら申し訳ありません
プラットフォームエンジニアリングでは
そもそもこういうものでしたよね
という振り返りになります
DevOpsから派生した考えだと考えております
その中でDevOpsをする中で
自分で作ったものを自分で運用しようという体制でやっていくと
なかなか運用上の辛みだったりとか
認知負荷が上がってくるよねというところで
それに対してプラットフォームエンジニアリングという手段を用いて
軽減できるんじゃないか
開発者の認知負荷だったりとか
会社体験を良くするための取り組みが
プラットフォームエンジニアリングと解釈しております
そのための手段として
よく皆様が耳に吸っているような
セルフサービス化だったりとか
IDPなどがあるのかなと思っております
すごく簡単でしたね
次ですね
組織規模においてプラットフォームエンジニアリング実践ということで
弊社の事例こんな取り組みをしてきましたという
お話をさせていただければと思います
最初の事例になります
弊社でやった1個目の取り組みなんですけれども
モジュラーモンリスの導入というものを行いました
これは約2年ほど前に弊社で
2年前から取り組んでいる内容になります
まずなぜこのような取り組みを始めようと思ったのかという背景について
お話しさせてください
当時の組織図の状況も合わせて伝えた方が
その時のなぜ使ったのかという
リアルなところが分かるのかなと思ったので
一旦組織図をご紹介させてください
私が入社した時2020年8月頃はこのような組織図でした
いわゆるプロダクト組織と基盤本部という
2つの組織に分かれていて
プロダクト組織というのは
箱物というアプリケーションの機能を開発するような組織ですね
フラットフォームエンジニアリング的に言うと
ストリームアラインドチームのようなものになります
当時はこのプロダクト組織のチームが
ワンチームで箱物というアプリケーションを見ていたんですけれども
組織の成長に合わせて4つのチームに分けていこうというフェーズで
4つのチームができたばかりのような状況でした
それに対して基盤チームはですね
SREチームと開発基盤チームというものがありまして
SREチームはいわゆる箱物の本当に
インフラ全てをまるっと見るような部門でして
開発基盤の方はこれからイネーブリングやっていきたいから
立ち上がった組織というような背景になります
私はこの当時開発基盤の方に
インフラとアプリがちょっとできるエンジニアとして
ジョインしたというような背景があります
当時の箱物の採用も結構
勢いというか頑張っていまして
人数がかなり今後増えていくだろうということが
予想されておりました
やっぱり人数が増えてくると
人数の増加かけるものですという問題が
起こってくるかなと思います
具体的なですね
コミュニケーションコストの増加ですね
一つのアプリケーションをみんなで見ているので
誰が何を知っているか分からないとか
正しい指標が把握できない
それ故に意思決定に時間がかかるみたいな問題が
起こるのかなと思います
またCICGの長時間化ですね
これはよく目にする事例かなと思うんですけど
一つのモノリスのアプリケーションを
みんなで開発するとやっぱりビルドだったり
テストに時間がかかって
顧客に価値を届けるのが遅くなってしまったり
それ故に開発速度が低下することが
起こり得ると思います
また成長機会の損失ですね
モノリスだとやっぱり
新しい技術を入れようとする時に
他のエンジニアのメンバーにも
意見を聞いたりとか
そういったコミュニケーションコストが増えたりとか
導入のハードルが高くなるという問題が
起こるかなと思っております
はっきり言って多分辛いんじゃないかなと思います
私はこれまでのエンジニア経験で
こういったいろんなフェーズの
企業でエンジニアリングをしていて
誰が何を知っているか分からないというのが
結構一番辛くてですね
正しい指標を把握している人で
誰なんだろうというので
結構エンジニアの中の経験の時間を
使ってきているような気がしております
そうならないためにも
何かしら今からできることがあるんじゃないかな
というところで取り組みを始めたという背景があります
もうちょっと当時の背景詳細に
深掘りしたいんですけれども
プラットフォームエンジニアの考えでいうと
チームファーストという考え方があると思います
少数のチームの方が信頼性が高く
ワークできるよねといったところとか
そのチームで適切に境界を設けて
他のチームとの境界を経てやり取りすることで
コミュニケーションコストなどが下がるんじゃないかな
といった考え方だと思います
当時の箱は左のような状態だったんですけど
右のようにチームに対して機能を
持てるようにするといったことを考えておりました
そのためのアプローチとして
マイクロサービスだったり
モジュラモノリストとかチームに対して
領域を設けるという技術的な手段があるかなと思っております
次ですね
プラットフォームエンジェリングについてなんですけれども
先ほど話したマイクロサービスも
モジュラモノリストも
セルフサービスかIDPもそうなんですけども
それは開発者の認知負荷を下げるための
手段の一つでしかないかなと思っております
当時はこの課題の温度感は
私がアサインされていて
マイクロサービス化ってどうだろうみたいなところだったんですけども
一旦そのマイクロサービス化を一気にいくんじゃなくて
フラットに今の自分の組織でできることって何なんだろう
というのを考え始めたというフェーズになります
次ですね
ちょっと話が戻るんですけども
当時いろいろ検討の上
モノリストには認知負荷を軽減する手段として
マイクロサービスとモジュラモノリストで
どっちかでいこうかなというのを検討を始めたような背景があります
このスライドすごく細かいんで
ちゃんと字は一旦終わらなくていいんですけども
ジェミニに生成させていって
マイクロサービスとモジュラモノリスト比較の表になりますね
右の内容は一旦置いておいて
左の軸だけ見てほしいんですけど
一番左の
これだけでも考えなきゃいけないポイントたくさんあるよね
というのが分かります
結局技術ってトレードオフなので
どっちかを選んだらどっちかのメリットが受けられないとか
そういったことが起こるのかなということを伝えたかったです
次ですね
今度はちゃんと見てほしいんですけど
今回の話でいうと
私が従ったプラットフォームエンジニアリングって
開発者の認知負荷を下げたいというところが一番だったんですね
この赤に塗っているところが
多分開発者に直接影響する項目だろうという表にまとめております
文字はちょっと見えないんで
後でスライド見ていただきたいんですけど
こんな感じで色付けしたところで
それぞれメリットがあるよねというのが分かってきました
ちょっと私の方で要約すると
モジュラモノイスはやっぱり既存のインフラ
既存のCICDのリソースを使うので
短期的に見たら開発者にとってすごくやりやすいという傾向はあるかなと思うんですけど
中長期に見たときにはやっぱり物理的に分離されていて
CICDも完全にマイクロサービス向けに作られていた方が
開発者の生産性は上がるし
中長期に見たらやっぱり高い
開発者的に見たら嬉しい点が多いんじゃないかなという整理をしております
ただですね
マイクロサービスを選択するというのは
結構僕難しい点が色々あるなと思っていて
これKubernetesの話でもそうだかもしれないんですけど
やっぱり分散システムを考慮する必要がありますよね
トランザクションどうしようだったりとか
そのマイクロサービスの切り方正しいんだっけなとか
そういった技術的課題が結構ついてくるかなと思っております
導入の初期コストは高いので
そこをどうページでやっていこうかなみたいな
結構迷うポイントかなと思っております
そうですね
なので変な切り方をしちゃうと分散モノレスみたいな切り方になって
結局嬉しくないってことになるので
どうしたものかみたいな当時悩んでいた背景があります
私のチームはどんな感じで整理していたかっていうのが次のところですね
結局技術ってトレードオフなんで
何かしらの判断をしなきゃいけないと思うんですけど
弊社の場合だとこのようなマトリックスで考えていました
ちょっと見づらいんですけれども
縦軸が組織と技術の成熟度で上に行くほど高いで
右軸が事業の方向性の確実度で右に行くほど高いという図になっております
もうちょっと具体的に言うと
組織と技術の成熟度はどういったものかというと
例えばですね
マイクロサービスだったり作っていこうとなった時に
インフラチームである程度知見を持っている人ってやっぱり必要だと思うんです
これからゼロでやるのはなかなかコストがかかるので
すぐに導入したいとなった場合には
その経験がある人がいるかどうかっていうのは
結構大きいアドバンテージかなと思っております
またプロダクトチームでいうと
アプリケーション側もマイクロサービスとして
考えて実装しないといけないと思うんですよね
べき等に作ったりだったりとか
リクエスト失敗した時の保証どうしようとか
そういった経験も考えていかなきゃいけないと思います
経験者がいてかつそれに対して
リソースが避ける状況かどうかっていうのが
縦軸の先ほどの組織と技術の軸との話になります
事業の方向の確実性っていうところで言うと
自分たちが扱っているドメインが
今後どう成長していくのかが
可視化されている
ドメインエキスパートの方がいたりだったりとか
またすでに枯れているドメインがいた
これだったら安定したインターフェースで
切り出せそうみたいな
そこが見えているかどうかが
結構判断の軸になるかなと思います
こちら先ほどの表ですね
いろいろ書いてあるんですけど
左下がモジュラルモノリストとして
技術も切るドメインも
まだあんまり不安定なんで
とりあえず始めてみるかみたいな
先ほどの表の左下の部分でして
左上と右下は技術はあるけど
ドメインが枯れていないんで
どうモジュールを切ればいいか分からないとか
技術はまだあんまり未発達なんだけど
そうですね
ドメインはモジュールはどう切ればいいか分かるみたいな
基本になってます
技術もあるし
こうドメイン進化するか分かってるみたいな
最初からマイクロサービス行っていいんじゃないかなと思っております
弊社の場合ですと
当時の状況を振り返ると
こんなプロットになっていまして
技術的には分散システムの経験があったりとか
マイクロサービスの経験ある人も結構いたんですけど
当時の課題観的には
既存インフラのリソースを割かなければいけない状況で
リソースの方でなかなか難しいなというような状況でした
またですね
ドメインという観点でいうと
当時箱本というサービスは成長段階にあって
今後どういう成長をしていくかで
正直はっきり答えられる人っては
あんまりいなかったんじゃないのかなと思っております
そういった中で
技術の事業の方向性の確実性でいうと
まだ高くないんじゃないかなというところで
モジュラモノリスから始めてみた
といった背景がございます
次ですね
実際モジュラモノリスはそこで始めてみたんですけど
どんなアプローチをしたかは
こちらの図になっております
至ってシンプルなんですけども
箱本というモノリスのアプリケーションの中に
モジュールの空間をコードベースで切れるようにして
モジュールに対してチームが
アサインされるような使われ方になっております
境界の分離ですね
弊社の箱本というアプリケーションは
レイルズで動いているので
レイルズで実現する上では
こういった技術を使っております
具体的にはパックワークという
ショッピファイさんが提供している
モジュラモノリスをサポートする
ジェムを使ってコード上の分離を実現していて
将来的にマイクロサービスに切り出すことも考えて
各モジュールのやり取りはプロトで定義させております
モジュラモノリスの作業の他の点としてはデータベースがごっちゃになっちゃうんじゃないかみたいな話があるかなと思うんですけど
それは論理的に分離する方針を取っていて
アクティブレコードのARプロキシーというジェムがあって
クエリが発火する前のタイミングで
どんなクエリが投げられるかチェックできるジェムがあるんですけども
それで正しいモジュールが正しいテーブルにアクセスできるかという
チェックする仕組みを作っております
最後にですね
先ほどお話ししたGitHubのコードオーナーをモジュールに
設定することを推奨していました
これによって正しい仕様を把握するチームが明確になるので
先ほどおっしゃった誰が何の仕様を分かっているか分からないみたいなところが
防げるんじゃないかなと思った次第です
決してセクショナリズムを進めたいとかではなくて
責任が誰を持つべきかというところを明確したかったという話ですね
こちらについても箱物テックブログというところに
記事は以前書いたものがあるので
詳しいことを知りたい方はそちらをご参照ください
次ですね
このモジュラーモノリスの取り組みのインタラクションモードの変遷になります
このモジュラーモノリス化というのは
そもそも予防的策で始めたものなので
プラットフォームチームが
当時という開発基盤チームですね
開発基盤チームがやっていきたいというところから出たので
自分で自分に対してセルフコラボレーションというか
そういうような形で
モジュラーモノリスを作る機能を作りました
具体的にはコードジェネレーターだったりとか
それをチェックするためのリンターだったりとか
レイルズ上で動くジムみたいなものを作っておりました
そこで大体ベースができたところで
実際にストリームアラインドチームに
2,3個、2個から4個のフェーズですね
使ってもらって
より足りない機能の実装だったりとか
ドキュメント化をして
そこまでいけたら
あとはそのドキュメントだったりを見てもらったら
ファシリテーションの形でいけるんじゃないかなと思って
4個以降はファシリテーションという形で
聞かれたら対応するみたいなフェーズを経ています
導入から2年経ったんですけど
結果どうだったのかという話でいうと
結果的には認知負荷を軽減できたケースとできていないケースが出てきました
具体的には認知負荷を軽減できたケースは
やっぱり新規の機能系の基盤系のモジュールは
比較的モジュール化がうまくいっております
狙ったわけじゃないんですけれども
今年に入ってAIを活用したコーディングというのが
皆さん使われ始めていると思うんですけども
そのモジュールという空間領域を切っておくことで
そこをAIに見させることで
コンテキストが絞られて
少ないトークンで効果的に扱えるみたいな
フィードバックももらっております
やっぱりこれはモジュラムの人だからではないんですけど
新しい機能って既存機能に依存しないものが多いので
かつ基盤系ってインターフェースが切りやすいので
モジュール化がうまくいったというパターンですね
逆に認知負荷が軽減できなかったケースになります
こちらはですね
いわゆる本当に箱本体側のユーザーが使う機能の
モジュール化というのは結構うまくできていなかったかなと思います
要因としては
マイクロサービスもそうなんですけど
やっぱり最初に切り出すのは重要なコアモジュールから切り出さないと
後からモジュール化するやつって
そこに依存する形になるので
無理なインターフェースでやり取りしなきゃいけなくなることがあるんですね
なんで
先にその周りのサブシステムから
モジュール化したら
なんでこんなAPI生えてるのみたいなのが
結構生まれてきてつらいなというのがありました
あとはその切り出したモジュールですね
ドメインが固まっていないため
切り出しが結構難しかったなと思っております
ドメインエキスパートがいたわけでもないですし
なんかここはマイクロサービスもきっと
だったとしても同じ課題に当たったかなと思います
ただ成果としては
フェイルファーストで切り出したドメイン
これおかしいんじゃないみたいな議論が最近起こりまして
ドメインの見直しっていうのを
ストリームアレンドチームと一緒に進めるようなきっかけになりました
モジュールモノエスなので
そのドメインの切り直しも比較的容易なので
そういった意味では最初からマイクロサービスに行かないで
一回モジュールモノエス挟んだの良かったかなと思っております
ちょっとこれ反省ですね
すごくちょっと浅い話になっちゃうかもしれないですけど
ファシリテーションモードに移行したってお話を
先ほどしたと思うんですけど
開発チームがファシリテーションモードに移行してからの
DevOpsやっていこうぜって意識めちゃめちゃ低かったなと思っております
当時の基盤チームはいろんなミッションを抱えていて
ちょっとモジュールモノエスの方ちょっと忘れ気味なところもあったんですけど
それ故に開発者側で起こっている
いろんな問題がちょっと拾えなかったって問題があります
全然接点とかもその当時なくて
時々こういろんなスラックのチャンネルで
たまに声かけられて答えるみたいなやり取りしてたんですけど
それをコラボレーションというかファシリテーションの仕方をしていたら
既存会社の問題に気づけずに
結構いろんな良くないモジュールが生まれてしまったみたいな背景があります
なのでちょっと改善としてちょっと安直な案なんですけど
今までこのモジュラムモノエスプロジェクトみたいな感じじゃなく進めてたので
プロジェクトっていうチャンネルを作って
今取り組むようにしております
それによってプロダクトチームと基盤チームの再路化っていうのがなくなって
一つの目的を達成するチームとして動き始められたなという実感は得ております
弊社はフルリモート企業なのでちゃんとやりたい案件ごとにプロジェクトを切っていくのは
多分いいアプローチかなと思うんですけども
多分物理出資者が増えている企業だと
それが多分オフィスレイアウトとかそういったところに反映されてくるのかなとは想像しております
この章で伝えたかったことをまとめになります
まずプラットフォームエンジニングの本質としては
やっぱり認知負荷の軽減こそが取り組むべき課題だと考えております
また全身的なアーキテクチャということで
段階を踏んでマイクロサービスセルサービスから持っていく手段もあるんじゃないかなという
テーションになります
あとは最後の反省に関わるところなんですけど
導入して終わりじゃなくて
継続的な接点を常に持ってやっていくという気持ちをちょっと忘れていたので
そこは丁寧にやっていきたいなと思った次第でした
導入事例1に話は以上になります
次に現在の取り組みのKubernetes導入のお話になります
こちらも背景からお話ししていきたいと思います
少し2025年の1月ぐらいまでのチームの状況だった
プラットフォームチームですねの状況になります
その当時のチームの状況4人で
大体8つぐらいのプロジェクトを見ているようなものを運営をしていて
結構引き継ぎされたものも多くて
結構認知負荷高いような状況で
この2025年1月を迎えておりました
当時は辛かったですね
チートポ本にある内容の抜粋になるんですけれども
早いフロー実現を阻害する8つの要因という話があったかなと思います
ここに書いてあるのがいわゆるこれらに定職していると
早いフローが実現できなくて
DevOpsが達成できないというものですね
当時の振り返るといっぱい定職してました
まず我々がチームファーストになる必要があるのではという気づきを得て
採用も頑張りまして
今人が増えて2チームに分割されております
上が箱物の
どちらもプラットフォームチームなんですけれども
上が箱物のインフラを見るチームで
下がマルチプロダクト基盤というチームで
共通のプロダクトが使われる基盤を使っていこうというチームになります
私は後者に所属しております
チーム分割してチームの認知負荷が下がったんですけど
やっぱり残っている課題がありました
プロダクト多すぎ問題ですね
プロダクト多くてそれぞれのCICD基盤を保守したりとか
その対応をやっていくのはなかなか大変という問題がありました
GitHub Actionsで統一はしていたんですけど
内部のアップデートって結構いろいろあると思うので
それをプロダクト数分やるのつらいなと思い始めた時期でした
あとファシリテーションのコストですね
このCICDどうやって使うんだっけみたいな
お問い合わせがプラットフォームチームに結構寄せられるんですけど
そうすると前向きの開発ができなくなってきて
そろそろセルフサービスやってもいいのではみたいなフェーズになりました
ちょっと待ってと
クバレデスって何か大変じゃなかったっけみたいなのが
僕2年前の記憶として思い出したところがあります
2年前何が大変だったっけなっていうのを思い出すと
当時言われていたのは学習コストめっちゃかかるんじゃないのかな
みたいな話があったかと思います
今ちょっと私まだ走り始めたばっかなので
間違ってるかもしれないんですけど
今学び始めてそんなに学習コストかかんないんじゃないかなと思っております
っていうのはECSとEKSと比べて基本的な概念は一緒で
内部的にどう動くかの違いだけだと思うので
基本を抑えるのは別にコストが高くないんじゃないかなと思っております
ただエコシステムがめちゃめちゃ多いですよね
つらいですよねいろいろ学ぶの
これを一個一個学ぶのは丁寧にやっていかなきゃいけなくて
そこの学習コストは一定払わなきゃいけないんですけども
OSSゆえに中身のコードとかが公開されているので
楽しく学べるんじゃないかなと前向きで捉えております
あとKubernetesの運用大変っていうのが2年前思ってたんですけど
今最近調べてみると多分NOかなと思っております
ECSに限った話になっちゃうんですけど
ECSのオートモードっていうのが2020年12月に確か出たと思っていまして
ここでKubernetesのいろいろめんどくさいがマネージド化されたので
比較的導入のハードルが低くなっててやりやすいんじゃないかなと思っております
具体的にはコントロールプレイのマネージド化だったりとか
リソースですねカーペンターだったりとかロードバランスのところも
ECSオートモードで一行記述したら多分使えるようになるぐらいになってると思うので
非常に楽になってきたんじゃないかなというふうな感触を得ております
今弊社なんで導入を決めたかというところで言うと
1個の課題ですね先ほどお話した通りプロダクタ数が増加して
基盤チームが大変になってきたっていうのと
あと2年の地震ということで
モジュラムモノイズを経てマイクロサービスをすべきものが見えてきたんで
Kubernetesがやっても意味が出てくるんじゃないか
載せれるものがあるんじゃないかというのが見えてきました
あとはですねECSサーバーレス運用の経験ということで
Kubernetesで失敗してもこの2年間で我々ECSサーバーレスで
たくさんAWSのインフラ作ってきてるので
戻れる自信があるから突き進めそうというのがあります
3つ目がタイミングですね
最近AIの発展によって社内でもたくさんアプリケーション作っていきたい
みたいな流れがちょっと出てきてるんですけど
そうなった時にガードレールの重要性っていうのが非常に上がってきたっていうのが
今年の動きかなと思っております
また加えて下の2つは先ほどご覧した通りですね
そういった3つの要因が重なって
セルフサービスでやっていこうという動きになっております
最後ですね
具体的に何やってるのかなってちょっと過剰書きになっちゃうんですけども
最近やってるのはいたって結構月並みな実装かなと思っております
必要を用いてサービスメッシュの実現をしております
今後生まれるプロダクトごとにネームスペースとバーチャルサービスを用意して
それらの開発者が安心して開発できる空間を提供したりとか
あとはGitOpsですね
今GitHub Actionsでそれぞれ作ってるのはArcoCGに統一することによって
利用者体験の統一CICGの仕組みの統一を図ろうとしております
ちょっとプラスチャレンジとしてはクロスプレイの活用をやろうと思っていて
やっぱりプロダクトが生まれるとAWSインフラの管理もなかなか大変になってくるので
それはプロダクト側に移動できないかなっていうことを考えております
最後にですねIDPとしてのバックステージということで
ここはちょっと正直運用コストとメリットどっちが天秤的に上がるか分かんないんで
ちょっと検討中な段階です
ということで諸々挑戦しております
また中間レポートが出せそうな場合はどこかでお話できたらなと思っております
最後にまとめです
この書で伝えたこととしたKubernetes導入ですね
プロダクトが増えてきたタイミングでプラットフォームチーム
人が無限に増えない限りは辛いので
Kubernetes導入というのも有効な選択肢になってきたなというのを
一企業として感じております
導入のハードルが2年前より明らかに簡単になってきているので
これから導入しようと人に向けては
いいタイミングなんじゃないかなと思っております
最後にバックアッププラン重要性ということで
挑戦の失敗がつきものなので
いつでも戻れる計画を持ってやるというのが
スタートアップには結構大事なんじゃないかなと考えております
この発表を通して少しでもプラットフォームエンジンが実現しようとして
皆様の参考になったら幸いです
以上となります
ご清聴ありがとうございました
はいありがとうございました
皆さん質問がありましたらQR読み込んで
お期待お願いします
早速質問があります
モジュラーモノリスを実践したときに
多くのドメインで共通されるコードのオーダーシップが
不在になりがちだと思いますが
そのあたりは問題になったり課題は出ていませんかということで
ご回答の方お願いいたします
はいそうですね
弊社だと多くのドメインといわれる共通で利用されるところというのが
基盤回りとか
あとはコアシステムの予約というところになるんですけれども
そこに関しては適切にチームがちゃんと設けられているので
今のところ課題にはなっていないです
というちょっと回答になります
はいありがとうございます
他に質問がある方
記載いただいてもいいですし
直接手を挙げていただいても構いませんが
いかがでしょうか
ありがとうございます
Kubernetesの導入のポイントのところで
最後の判断式のところに
AIガードレールの重要性みたいなのが一つあったと思うんですけど
直接換気しているのかなというのがちょっと気になって
どういったところにそこの判断ポイントに関わったのかなというのを知りたいです
はいそうですね
弊社の場合ですとこのAIの発展によって
エンジニアに限らずいろんな職種の人も含めて
プロダクトを作っていこうみたいな取り組みが今起こっていまして
それを今までのAIが出る前ですと
エンジニアがインフラを整備して
それにちゃんと自分たちでガードレールを引いて実装するというのがあるんですけど
その需要と供給に追いつけなくなってきたなというのがあります
今の弊社のタイミングですと
Kubernetes上に安全にアプリケーションを使える仕組み
例えばですけど
セキュアに個人情報が出ないようにしたりだったりとか
ログに流れないようにしたりとかですね
そういったものをKubernetes基盤のレイヤーで吸収できたらなというような意図になります
AIによるアプリがたくさん増えてしまって
それを動かす基盤をそれぞれ作るのが辛いから
Kubernetesで解決できないかなみたいな意味合いでした
ありがとうございます
スライドで質問がもう一点あります
いざマイクロサービスを導入してみて
分散モノリスにならないような施策として何か意識しているものはありますかと
そうですね
今の弊社のフェーズでいうと
Kubernetesの基盤をやっと作り終わったところで
これからアプリケーションを載せていこうというようなフェーズなのです
なのでまだ実際にこれからやってみて分散モノリスになりそうかなというのは課題としてあるんですけれども
まずは弊社の場合だとモジュラモノリスでのモジュール化したもので
明らかに他とバッティングしないものというステップがあるので
そのモジュールたちをマイクロサービスに載せるという
結構安全に進めているところはあります
なので銀の弾丸的にいきなり切り出して分散モノリスにならないみたいなのは
ちょっとなかなか考えられていないですね
という回答で大丈夫でしょうか
はいありがとうございます
最後の質問もし何かありましたら
ご視聴いただけると幸いです
質問ありがとうございます
プラットフォームのエンジニアが結構すごいアプリケーションの設計周りを
すごい手を入れ加えているなみたいな部分があって
結構そこら辺アプリケーション側はアプリケーションのチーム
プラットフォームは下のインフラレイヤーみたいな感じで
分けられているケースがすごい多くの会社で見られると思うんですけど
アプリケーションの設計に携わっていったのは
もともとそういう思想で携わっていたのか
自分たちがやらせてくださいという形で入っていったのかはどっちなんですか
後者になりますね
もともとその組織課題に対しての課題解決をしようと思ったのが
プラットフォームチームだったので後者の流れになります
たまたま私がインフラもレイルズもできるみたいなレイヤーだったので
自分でやった方が早かったなというのが当時の印象です
ただそれで先ほどお話した通り
うまくコミュニケーションパスが取れなくて
回らなかった点があるので
今後同じようなことがあったら
ちゃんとそれぞれのレイヤーごとにやるかなと思っています
ありがとうございます
はいありがとうございました
皆様ご清聴ありがとうございました
登壇された方に改めて拍手お願いいたします
拍手