最近気づいたこと
こんにちは。
全然記事も書けてないし、Playful-Coreも進んでないし、自分の勉強も進んでいないTomofilesです。
転職準備で自分のキャリアと向き合うのが大変で、なかなか思うように進められないですね。
最近作業が進んでいないのも、色々視点や視野が変わってきて、新しい知識も入ってきて、
そっちに舵を切りたくなってしまって、作業が手につかないということが発生しているからなのですが、
ここらで今気づいたり、悩んでいることを一度アウトプットしておこうと思いました。
Playful-Coreどうなった
Scheduler完成して、つい最近、新生Reservationが完成したばかりです。
いまRecordingに取り掛かるところですが、そこで止まっていますね。
それがなんでかというと、Kubernetesの勉強を始めたのですが、
やっぱりノー知識で取り掛かったからですが、全体構成がちょっと問題ありと
わかってしまったのです。
あとは、最近見つけた以下の記事が、最高に衝撃的でした。
最近よくサービスメッシュって聞くなぁと思って色々調べていたときに見つけたのですが、
アーキテクチャの変遷・背景をこうやって整理して知っていくと、
やっぱり部分適用というか、ボトムアップ的にIT技術を見てもダメだなぁと感じたのです。
トップダウンでIT技術を見てみる
業務システム界隈にいるとどうしても自分ごととして関心を持つことが少ないですが、
世の中のビジネスのITは、２４時間ノンストップで稼働することが前提で、
常にサービスが稼働×常にサービスを開発＝価値・利益
というのがITに求められていることなのです。
そのためには、稼働し続ける安定した基盤と、新しいサービスを常にリリースし続ける、
ということを両立しないといけないですが、それを実現するのが非常に難しいのが、
従来のアーキテクチャだったのです。
マイクロサービスアーキテクチャが台頭し始めたのも、これを実現したいから。
アーキテクチャの複雑さと、サービスの稼働と開発を両立させることを天秤にかけたとき、
後者を取ることが、自社の事業を展開する上で重要な戦略だということですね。
この視点で現在のシステムアーキテクチャを眺めてみると、非常にしっくりきます。
システムが安定稼働するというのは、コンピュータのハードウェアからお手入れが必要です。
ディスクが破損したり、電源に不具合が発生するというようなことは、
サーバーを抱えていれば往々にして発生します。
クラウドコンピューティングは、計算能力を従量課金性で使用でき、何よりこのハードウェアの
メンテナンスをする必要がありません。また、近年のマネージドサービスの充実も相まって、
「組み合わせて」「利用する」ことで、サービスを展開することができる。
安定稼働のハードウェア面の革新は、クラウドですね。
※今朝知りましたが、ブロックチェーンのマネージドサービスが展開されるようです。
もう死角がないですね。
AWSのマネージドブロックチェーンサービスが一般に公開 | TechCrunch Japan
そして、ソフトウェア面では、コンテナとオーケストレーション技術です。
私もよくわからずKubernetesを使ったり、機能を勉強したりしていましたが、
ソフトウェアのスケールや構成変更などを、安定稼働を維持したまま適用できる、
というのが、これら技術のキモなんですよね。
私は、Kubernetesの勉強をしながら、いまのPlayful-Coreの構成が全然この流れを
汲めていないことに気づいて、全部を作り直したくなりました。
コンテナはイミュータブルな実行環境で、突然切り捨てられても構わないようにしないといけない、
だからスケールアウトに柔軟で、可用性があって、セルフ・ヒーリングが有効に働く。
宣言的設定によって、「定義したとおりに環境を維持し続ける」。
Playful-Coreはそういう意味で、色々問題があります。
MQTTはまず、Kubernetesと相性が悪いです。
MQTTはテレメトリデータ（一定間隔のセンサー情報など）を処理するのに適していますが、
ロストを許さないデータをやり取りするには、向いていません。
Playful-Coreでは、重要なイベント情報をやり取りしています。
そういう意味で、接続を維持しつつ、必要に応じて切り捨てられるコンテナで動作するというのは、
イベントのロストを許容していることになり、アーキテクチャとして信頼性がありません。
それに、MQTTはM2Mなので、スケールアウトに向いていないのです。
単純にサービスをスケールアウトすると、そのサービス向けのメッセージが複製され、
同一メッセージが複数処理されることになります。
べき等性を考慮すればいいかもしれませんが、無駄な処理にリソースを割くことになり、
非効率です。
また、Scheduler、Recodingの２つのコンポーネントが、ステートフルになっています。
スケールアウトが全く出来ず、また、コンテナが切り捨てられると、全てが吹き飛びます。
マイクロサービス化をしていくなら、状態はデータベースなどのミドルウェアに格納し、
各サービスはあらゆる状態を保持しない（セッションも、メモリ上のデータも）ようにしないといけません。
まぁ、ミドルウェアにいい感じのタイマーが無いから、Schedulerを作ったのですが、
やっぱりちゃんと考えて作ろうと思うと、問題はたくさんあります。
スキルとして不足していること
ハード面、ソフト面から、世の中の潮流と、自分の現状を比較してみました。
クラウドサービスは、とにかく勉強するしかないですね。
あとは、マネージドサービスも色々展開されていて、こういうのの動向を追ってくのは重要そうです。
最近スキルの棚卸ししてて気づいたことなんですが、
やっぱり圧倒的な物量で品質担保するのが業務システム界隈のやり方で、
テストケースの観点・網羅性と、アナログ的テスト消化による品質担保が、
現状の私のやり方になってしまっているなと。
観点や網羅性の考え方・視点は重要だなとは思うんですが、
テスト実行の方は、もうちょっといい方法があるのではないかと思うんです。
継続的インテグレーションである程度のテストを自動化することは、まず重要ですね。
ただ、マイクロサービス化したコンポーネントの、何をどこまでテストを自動化できるのか、
そこが今の疑問です。
ソフトウェアの開発プロセス全体で見たときに、継続的インテグレーションがどのように、
「目的」「適用範囲」という問題領域を持っていて、どのように解決するから有効なのか、
全体感を知りたい。
いい書籍とかありますかね。
アジャイル開発による品質担保と、サービス価値を維持・向上する方法論的な。
これってQAとかSREとかって分野なんですかね。
だめだー、勉強が足りない！
