クラウドの作り方 (使い方じゃないよ) – NTT Com Open TechLunch #2
https://nttcom.connpass.com/event/263134/
に参加してきたので、そのときのレポート

クラウドの作り方

DC NW x ソフトウェア

Data Center を作る。ラックとか空調管理とか。

物理装置を扱う

• ハードウェアがちゃんと動くかとか
• 100G bps のテストに耐えられるかとか

ネットワーク試験を自動化
大量のテストがある
テストログだけで7000万行くらい出てくる
そのログの解析も自動でやる

 

物理配線の切り替えロボットの導入

 

そのように

• ネットワーク x ソフトウェア
• ハードウェア x ソフトウェア

を意識して開発している

SDN/NFV x ソフトウェア

SDN とは？簡単に

ネットワークを切り替えるソフトウェア

SDN コントローラーの経路計算遅延解消

この辺はよく分からなかった
冗長な実装があって、アルゴリズムを改善したら、かなり早くなった、という内容っぽい

ディスカッション・質疑応答

Q1

このクラウドはどうすれば使えますか？

A1

法人向けのサービスなので、法人向けの営業の方から連絡とってもらって、となる

Q2

社内（今回説明していただいた事業）での内製と委託の割合は？

A2

ちゃんと測っているわけではないが、内政がまだ半分いってないくらいかも？

Q3

配線ロボットは何者？

A3

実際の配線を物理的に切り替えてつないでくれるもの。
配線ロボットは探せば売ってるものがある。
いま使っているものが面白くて、大量の線を扱うが、線がからまることがないという特許を取っている。

Q4

人材は取ってくるんですか？育てるんですか？

A4

もともと育てることが多く、いまでもそうしているが、昨今人材不足もあるので、とってくることもしている

Q5

長期インターンシップとかやっていますか？

A5

なんらかの形で今後そういう場が作れていければと思っている

Q6

どういう言語で開発されてるんですか?

A6

それぞれのチームで決めているが、自分のチームでは Python, Go, C++ が多い。
Ruby を使っているチームもあるし、Rust とか流行ってきていたりもする。

Q7

クラウド基盤の開発や検証を担当しているのですが、クラウド基盤ソフトウエアベンダのパッケージソフトを使っていて、さらに各工程ごとに分業で実施しています。社員はほとんど管理業務しておらず、システム更改の開発規模もおおきく、重くて、新しいことにほとん度取り組みできていないです。どのようにしたら飛岡さんの発表のように開発が回せるでしょうか？アドバイスいただければと思います。

A7

どういうことを自動化していけるか考えていく。
内製していかないと自動化も難しい。
業務委託をきるというよりは、いまの作業を少しでも自動化していけないかを検討したりしている。

Q8

クラウドを提供していて大変だったこと、言えるポストモーテムはありますか？

A8

一番低いレイヤーまで自分たちでチューニングできるのは醍醐味だと思う。

Q9

物理的な作業のドキュメンテーションはどのようにされていますか？作業手順など、写真を取ったりとかなのでしょうか？

A9

配線など、大量の作業をしている。数%のミスだとしても何本か間違ってしまうことがある。
そういうのは実際に現地に行って写真を撮って確かめたりする。

Q10

NTTグループ間でのエンジニアの交流とか気になっています。

A10

交流はあって、今日のテックランチとかも社内でもともとやっていたこと。
t_wada さんの読書会とかも。
割とボトムアップで交流会が生まれたりする。
なので交流はチームを跨いでできるかと思う。

Q11

コードは書けないけどインフラ構築経験はある、みたいな人に席はありますか？

A11

自分にできないことをしてくれている人はとても重要で、多種多様な内容を専門にしている人がおり、他の作業をやっている人をリスペクトしている
他の作業に関して全く知りたくないとかだと良くないかもしれないが、一緒に協力しながら仕事をしている。

クロージング

次回も乞うご期待！

#techlunch 登壇を終えました。ご参加くださいました皆様、ありがとうございました！

そして次回予告はこちらです。乞うご期待。 https://t.co/a5yf7bT58P pic.twitter.com/SMBi2z5I1p

— Takuto Wada (@t_wada) October 27, 2022

参加して個人的感想

日頃あまり触れないレイヤーの話だったので、とても新鮮で面白かったです。（こなみかん）

物理的な配線作業はなんとなくのイメージで、手作業でやるのかなり神経使いそうだなと思っていたのですが、ロボットがいることは初耳でした。（線が絡まない特許すごい）

社内チャットのスクショをみせてもらいましたが、コードの改善についてわいわいやりとりをしていて、おっしゃっていたように周囲の方をリスペクトしながら働いていらっしゃるという感じがしました。

また、大量の作業やテストを行うので、ロボットの導入をしたりテストを自動化したりなど、話にもあったように自動化が思っていたよりも重要だということも分かりました。

 

リアーキテクチャことはじめ～事業成長を最大化するための技術選定と登り方～

https://flexy.connpass.com/event/259853/

に参加してきたので、そのときのレポートです。

 

レガシーの定義とは？

今回のレガシーの定義では

と定義します

ここで大事なのが４で、簡単な機能追加に時間がかかってしまうことがある。
そこで、リアーキテクチャが必要になってくるが、
単に「このシステムは今ここがよくないのでこうすべき」というのは誰でも言えるが
将来の事業成長や拡張性を見据えてどうするか、ということも考えられるのが必要になる。

そこで、今日はリアーキテクチャをどのようにやってきたとかの話を事例を交えてする。

各社サービスの背景からみるリプレイスの事例

事例1

バージョンアップしたいが、なかなか難しく、負債が高まっていっていたため、リプレイスを検討した。

リプレイスを検討していると
現状のシステムを分析した結果、複数の境界線を跨っていることがわかった
そこで、記載しているような設計にした。
稼働年数10年とあるが、システムをリプレイスするのは稼働年数と同じくらいかかる。
今1.5年ほどリプレイスを進めているが、まだ序の口。

とある業務フローがあり、
伝統的なシステムだと、とあるデータを同じデータとして扱いたいが
業務フローを精査してみると、違うデータとして扱う必要がある。
例えば、セブンイレブンにあるお弁当とかは、全部同じものではなく、店舗によって近い工場で造られている
お弁当の申請をするとそれはパートナーが登録したデータだが、申請されたデータを承認するのは別の工程で行う。
それを処理するには、申請されたイベントから派生させて行うのが良いとなり、そうしている。

事例2

最古の commit が 2012 年だが、それ以前にも何かあったらしい。
一番社歴が長い人でも5年前で、その人に歴史を確認しながら進めることもある。
中身を見ていると、名前がおかしなものもちょいちょいある。
改修の際に調査が長引いてしまいデリバリーが遅くなることがあり、リプレイスを検討した

1日30分くらいつかって地道にLaravel に載せ替えることもしていたが、長続きせず頓挫することもあった

現在は本腰をいれてリプレイスを進めている。
いま進めているリプレイスも何年かかるか分からないが、進めている状態

リプレイスする際に、ちゃんと技術選定していかなければならない。
Rust を採用した理由は？と聞かれて「流行ってたからです」となると
未来で困る人がその理由は聞きたくないだろう。

事例3

読み取りと書き込みは別要件なので、それぞれ別個に最適化したような設計をした

事例4

内部事情を知らないといけないので、入った人が戦力になるまで時間がかかる

コードベースでモジュラーモノリス化した

事例5

マイクロサービスアーキテクチャ化をすすめている

マイクロサービスアーキテクチャにするとビジネスが推進されますよという見出しの記事がよくあるが
それを行うには何年単位という時間が必要になる
ドメインを分析したり、業務フローを精査したりなんなら業務フローを変えたりする必要もある
もろもろ全部考えた上で、決断する必要がある。
なんのためにマイクロサービス化するのか、技術ファーストではなく、ビジネスのためにどうするのか、というのを考える必要がある。

Q&A

Q1

リプレイス後のアーキテクチャはどのように決められましたか？トップダウン、ボトムアップなど。また、ボトムアップの場合で、メンバー間で意見があわない場合はどのようにアーキテクチャを決定されましたか？

A1

あらたまさん

トップダウンだった
現場で、どうすればいいか分からないという状態だったので、トップダウンで行った
また、リプレイスというのは向こう数年にわたって投資をしていくという判断なので、経営判断が必要になる
のでボトムアップだけだとうまくいかないと思う。
経営的に、いまここに投資するべきか、という判断をしている

ytakeさん

トップダウンだけでいくというのはあまりやっていない
メンバー間で意見が合わないばあい
スキルセットが合わない人ももちろんいるので、ディスカッションはする。
が、技術レベルを下げることはあまりしない。そこを下げてしまうと、周りが面倒をみる必要が出てくるし、会社の技術レベルが下がってしまう。
ので、習得してもらうようにしている

Q2

言語やフレームワークを大きく変更したとき、メンバーに対するキャッチアップはどのように実施されていますか？（ex. 週1で学習時間を設けているなど）

A2

あらたまさん

輪読回をしたりしている

ytakeさん

技術習得が難しい人もいるし、本だけだとわかりづらいところもあるので、質問があれば自分が噛み砕いて答える、ということをやっている
エンジニアだけに限った話じゃないが、技術習得のアップデートというのは当たり前ではあるので、そういうのを自主的にやっていけると良い

Q3

リプレイス中に仕様変更がある場合、どのように取り込んで開発していますか？

A3

あらたまさん

リプレイス中の使用変更はブロックするようにする

ytakeさん

やらないといけないことあやるようにしている

Q4

退職者が多いことによる辛み=技術的負債とした時に、リプレイスに時間が数年かかるとなると今作っているものを以下に負債にしづらくするかというのが大事だと思っています。そこに対する取り組みとかありますか？(ドキュメントは工数がかかりすぎたり、陳腐化する懸念がありどう考えているか伺いたいです)

A4

あらたまさん

ドキュメントはコンフルエンスとかにたくさん書くだけではなくて、コードコメントとかも大事なドキュメント
細かくドキュメントを残していけるかが、システムの寿命にもなると思う

ytakeさん

陳腐化するのか防げないので、定期的に確認する必要がある。
書いた人の考えていることの一部を読んだ人が得られるので、劣化した情報が伝わっていくので陳腐化は防げない
ので、定期的にメンテナンスする必要がある。

まとめ

ytakeさん

作るものだけを考えるのではなく、技術ファーストではなくビジネスのことも考えよう

あらたまさん

サービスや事業に対する理解を社内の人とたくさん話をして解像度を上げていく必要がある
自分の考えた最強のシステムを作りたくなる気持ちもあるが、そこを抑えて考えていく必要がある

参加しての感想

イベントの中でも出てきましたが、リプレイスはしなくて良いのであればしないほうがよく

日頃の業務の一部をリプレイスに投資するという判断をしなければならないので

ある程度ストレスがかかることもあると思います。

また、リプレイスをするというのは現状の負債と立ち向かうものなので、作業自体にも結構な負荷がかかると思います。

全体的にですが、そんな話を笑いも交えながら話をしてくれてとても安心しながら聞けました。

また、リプレイスは単発で終わるものではなく、数年かけて行うこともあるので

何をどうするということをしっかり決めたり、どういうプロセスでやっていくのかという計画を立てたりすることが重要だとあらためて感じました。

何度か出てきましたが、技術ファーストで考えるのではなくビジネスのことも考えていこうというのはとてもうなづけました。

いまのレガシーなシステムでつらいことを感じることもありますが、それだけの理由でリプレイスしたいというのは目線が自分に向いているので、ビジネス目線でどうなのか、ユーザー目線でどうなのか、ということまで考える必要があると、改めて感じました。（つらいのを許容するべきという意味ではない）