FTPのアクティブ/パッシブモードについて
目的
FTP接続のアクティブ/パッシブモードについてとデータ転送の関係などについて調べる必要が出てきて、色々と新たに知ることも多かったので備忘録を兼ねてまとめておく
FTPの接続モードと詳細
FTPについての基本情報
アクティブモード
パッシブモード
- デフォルトではコントロールコネクションにTCP/21番ポート、データコネクションには毎回ランダムで決まるポート番号Tを使用する
- 通常はセキュリティ上、対象のポートレンジを指定してそのポートはファイヤウォールで許可しておくといった設定で利用される
アクティブ、パッシブ以外のモード
- アクティブ、パッシブ以外に「EPSV（拡張パッシブモード？）」というものもあるらしい
参考
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略の読書メモ
及川卓也さん著のソフトウェア・ファーストを読んでみたので、その読書メモ
はじめに
IT業界、エンジニア業界で著名な及川さんが書かれた本ということで存在は知っていたので、本屋に立ち寄った際に目次をパラーっとみて見たところ、 「ソフトウェア・ファースト」とは何を指しているのか？また、「ソフトウェア・ファーストなキャリア」という見出しや章が気になったので購入し、読んでみました。
読書メモ
前半
ソフトウェア・ファーストとは
前半はソフトウェア・ファーストとは、から始まり、
ITやソフトウェアにおいての日本とそれを取り巻く世界の現状と課題、 そして、その課題に対して必要な変革について述べられていました。
以前の主流であったパッケージ型のソフトウェアではなく、 近年はSaaSなどによる産業のサービス化が主流となり、これまでとは開発の進め方やビジネス、サービスの考え方が大きく変わって来ている。
それに対応するためにIT活用やソフトウェアを核として課題解決をし、事業や開発を進めていく考え方がソフトウェア・ファーストとのこと。
日本が抱える課題とは
日本と欧米ではソフトウェアに対する考え方や関わり方があり、日本ではイノベーティブな開発が行いづらい側面がありそう。
日本は品質に対しての意識は高く、これまで製造業で培ってきたものがある。
「狩野モデル」を利用して、開発するソフトウェアやサービスに求められる品質を正しく定義することで、このような課題を解決していけるかもしれない。
あれば満足だが、無くても仕方ないと思われるような「魅力品質」がイノベーティブなプロダクト開発に繋がっていく。
今まではユーザーが欲しい物を作っていた時代だったが、今後はユーザーが欲しいものを見つけていく時代に移り変わってきているので、 時代の変化に合わせて考え方や開発の進め方なども変化や進化が必要。
後半
エンジニアのキャリアについて
後半はソフトウェア・ファーストな組織キャリア
キャリアパスについては前職や今の職場などでも同様のロールやポジションがあるため、個人的にはその定義の再確認といった部分が多かった。
ただ、近年よく聞くがイマイチ分かっていなかったエンジニアリングマネージャーのロールや、テックリードとの違いについてはこの本を通して何となく掴めた気がする。
しかし、結局は会社・組織毎に肩書とロールが異なってくる部分もあると思うので、あくまでも目安、参考情報として踏まえつつ、それぞれの文脈や組織によっての変換は引き続き必要なのだろうと思う。
及川さんのこれまでのキャリアについて
また、後半でとても興味深かったのは、及川さん自身のいままでのキャリアでのターニングポイントと、その時々に感じていたことなどがまとまっていた部分。
第一線で数々の経験をされてきた方の今までの変遷や足跡を辿ることで、 誰もがぶつかるであろう悩みや課題を同様に抱えていること、またそこに対してどのようなアプローチ、行動をしてきたのかということは今後の参考しつつ、今までの自分に足りなかったこと、今後必要なことの見直しにも繋げていければと思った。
全体を通して
まだまだ、うまく自分事に落とし込めていない部分などもあるので、時間を置いてまた読みつつ、自分が置かれている状況や今後の自分のキャリアやエンジニアとしての生き方について考えたいと思いました。
Kyash Meetup #7に参加してきました
Kyash Meetup #7
We are Kyash Direct 2019/11/14@Kyash
KyashさんのMeetupに参加させていただいたのでそのメモ。 最初にCTOの方からKyashやKyash Directについての説明があり、その後、各エンジニアのLTセッションがあって最後に懇親会という流れだった
LT 1 : Welcome to Kyash! by 椎野 孝弘さん
- KyashDirectのエンジニアは4人
- 全員サーバサイドエンジニアでフロントエンド専任はいないとのこと
- ビジョンは価値移動のインフラを作る
- お店や人々、そしてお金などの移動をスムーズに行うことでよりよい世の中にしていく？
- これまでの主な歩み
Kyash Directとは？
Kyashの特徴
- イシュイング
- Visaカード発行ライセンス、前払い式支払い手段を取得
- プロセッシング（決済処理）
- アプリケーション
- イシュイング
Kyashの今後の展開
LT 2 : 知識0からはじめる決済処理 by 松雪 俊さん
カード決済について
- 請求的なことはクリアリング（売上確定）という ※その他カード決済に関わる用語、事業の概略について説明されていました
アーキテクチャ
- DDD(clean architcture) & MicroService
- 各マイクロサービスはMessageBusで結合
- sagaによる補償トランザクションで一貫性を確保
質問であがった内容
LT 3 : サーバーサイドエンジニア集団のためのElm by 鈴木 亮太さん
- 管理画面について(Elm製)
- Elmは静的型付け関数型のJS
- アーキテクチャ
- TEA(Model -render-> View -message-> Update ---> Model)
- Elmのメリット -> 考えることが減る。サーバサイドエンジニアばかりのKyash向き(フロントエンジニアはいない)
- Kyashでもtech lunchがあるらしい
LT 4 : 入門Certificate Transparency by 村上 孝則さん
質問で上がった内容
- なぜ".co"なの？
- kayash.comはすでにインドの会社に取得されていて使えなかったため
懇親会
サービス設計について
- 法律や専門知識など関わってくるところもあるのでリーガルやエンジニアなどみんなでわっと集まって話したりしているのか？
- そういうフェーズもある
- 最初のフェーズではマネージャーなどが集まって決めている？ ※ここよく分からなかった・・
- 法律などはかなり専門的な知識が必要になるので、その辺りはもちろん気を払って対応している
- そういうフェーズもある
- 法律や専門知識など関わってくるところもあるのでリーガルやエンジニアなどみんなでわっと集まって話したりしているのか？
インフラ
- AWSを使っている。現状はKuberntesマネージドなどは使っていないとのこと
- KyashDirectの開始でだいぶ収益も上がってきた
- 歴の浅いメンバーも多い中で情報やドメイン知識などのナレッジ共有はどうやっている
- 入社前の推薦図書があり、入社前にそこで最低限の知識はためておく
- 人数も少なく風通しも良いため気軽に質問できる雰囲気がある
- ドキュメントなどが整備されていないため、新規のメンバーなどがドキュメント化などのアウトプットをしつつ学んでいく
- その他
- 当日の参加者には入社予定の方やカジュアル面談を経て参加されている方もいた様子
- 大半のエンジニアがここ1〜2年以内に入社されたメンバー
感想など
まずはオフィスが意外にもオープンな雰囲気があり、当初のイメージや金融周りの事業のイメージとだいぶ違った感じのオフィス、組織だなと感じた。 また、今回の登壇者の方々は全員、入社半年以内ということだったが事業やサービス、決済に関する知識をしっかり持たれていて、技術力だけではないエンジニアが揃っているのだなという印象を強く感じた。 それと同時に、メンバー皆Kyashのサービス愛もすごく感じて良い雰囲気の会社、チームだなというのも伝わってきました。 その影響もあってか懇親会もとてもフランクで話しやすい雰囲気でLT含めてとても良い時間を過ごさせていただくことができました。
LTのアーキテクチャの話が今回は一番興味がある話だったので、DDD+マイクロサービスを使っていることやSagaパターンを利用していることが知れた一方で、 モデリングや設計、運用についての話ももっと聞きたかったなというのが心残りでしたが、とても良い機会でした。ありがとうございました!
CODE COMPLTE 第1章 読書メモ
背景
ソフトウェア開発に携わるものとして読んでおくべき名著としてよく名前のあがるCODE COMPLETE。 上下巻揃えたものの、今ままでかいつまんで一部分読む程度で「ちゃんと読んだ」と言える状態になかったので、あと２ヶ月弱となった今年中に気になった箇所だけでも、しっかり読んでおこうと思い立ち、読み進めるとともに、後から見返したりできるようにちょっとしたメモがわりにこちらに書きました。
読書メモ
1.ソフトウェアコンストラクション
ソフトウェア開発の大部分を占める、開発の中心的なアクティビティのこと。どのプロジェクトでも必ず実行される唯一のアクティビティ。
コンストラクションのほとんどの部分はコーディングとデバッグだが、設計や計画、テストといったアクティビティも含まれる
コンストラクションは機械的なものでなく、創造力と判断力を必要とする
結果として、コンストラクションの方法をどれだけ理解しているかが、どれだけ優秀なプログラマであるかを決める。
2.ソフトウェア開発への理解を深めるメタファ
よく理解できないものをよく理解できるものと照らし合わせた結果、何かがひらめいて、解明できなかったテーマへの理解が深まることがある。メタファのこうした利用を「モデリング」と呼ぶ
メタファは、ソフトウェア開発プロセスを既知のアクティビティと関連づけることでその理解を促進する。
メタファをどれだけ理解できるかによって、ソフトウェア開発をどれだけ理解できるかが決まる
ソフトウェアメタファは「アルゴリズム」というよりも、「ヒューリスティクス（発見的）」という意味合いが強い。見つける方法を教えるだけで、何を見つけるのかは教えてくれない。 答えを見つけるために役立つテクニックの一つ。
ソフトウェアに関するメタファには様々なものがあるので、目的にあったメタファを組み合わせて利用すれば良い。
3.上流工程の必要性
プロジェクトの成功の行方は、コンストラクションが始まる前に大方決まってしまう。 コントラクションの前の下準備である、アーキテクチャ、設計、プロジェクト計画といった上流工程が大事。
準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである
準備を事前にどの程度まで完了しておくかについては、ソフトウェアの種類、プロジェクトの形式、技術的な環境、スタッフのスキル、プロジェクトの目標によって異なる。 大抵のプロジェクトは高い反復性を必要とするが、プロジェクトによっては逐次性を重視する場合もある
課題定義が十分でないと、コンストラクションの際に解決すべき課題ではなく、誤った課題を解決する羽目になる
要求の策定が十分でないと、課題の重要な特徴を見逃してしまう恐れがある。
アーキテクチャの設計が十分でないと、コンストラクションの際に解決すべき課題はあっていても、誤った方法で解決する羽目になる
プロジェクトにおいて、コンストラクションの準備がどのように行われたかを理解し、それに応じてコンストラクションのアプローチを選択する
4.コンストラクションの重要な決断
第1章の振り返り
ソフトウェアコンストラクションという、開発の大部分を占める作業についての定義や、それに関わる準備から実践までの作業の必要性、重要性について説いている部分で、 自分の感想や感覚としては、今までやってきたことや、ソフトウェア、サービス開発とはこういうものだというのが丁寧に整理され、言語化されていたのがこの章だと感じた。
アーキテクチャの部分については、自分は基本的にwebサービスしか携わってこなかったため他の分野ではこういうところに着眼するのかということが、ざっと見レベルだが垣間見れたように感じた。
1章の中では、自分は特に「メタファ」についての箇所はとても興味深かかったと感じた。 最近、思考法についてやDDDについての本を読むことが多く、どちらでも必要かつ重要な概念・スキルとして「抽象化」が取り上げられていたが、その抽象化を行う過程で必要となるのが「メタファ」であると考えている。
特に本書で、ソフトウェアのメタファについて、「ヒューリスティクス（発見的）」であるとされている点については、なるほどと思わされた。 今まで、何かしらの「答え」を探して「答え合わせ」をするようになってしまっていた部分が多く、 何かが違う、うまくいかない、と感じていた部分が、この言葉ではっきりしてきたように感じられた。
もちろん、ここが言語化されてクリアになったところですぐに何かが改善できるわけではないと思うが、今後はこの勘違いの沼に今後ハマらず開発を進めていくきっかけにはなりそうだと思う
今は次の2章を読んでいるところだが、ボリュームも多く内容もぎっしりなので、いつまとめられるか、そもそもまとめられるのかどうか不安・・
転職して1年が経過したので振り返り part2
現職に転職して約1年経過したのでその振り返りのPart2 Part1はこちら
2019年1〜10月
仕事面
年が明けて入社して3ヶ月くらい経ったので、少しずつ慣れきたりナレッジも増えてくる一方で、 思ったほど成長や成果を感じることがないなと思って焦り、序盤は朝いろいろ調べながら学んだり、なるべく数多くのタスクをこなそうとしていたように思う。 今振り返ると、自分に必要だったのはもっと1つ1つのことの集中して、その背後や周辺知識などをしっかり固めておくことだったように思うが、 当時は数や幅にこだわり中途半端な感じになってしまっていたように思う。
その後は結婚式の準備などでバタバタし、プライベート優先の期間があったため、そこで少しペース置いた後に、 また元のペースに戻して、今度は仕事の幅やレベルを中心に考えるようになったが、まだまだなんとかこなしている感が拭えず、調整ごともうまくいかないなど反省や後悔することも多い期間を過ごしていたように 今振り返ると感じる。 ただ、この期間の反省やここで焦った結果の行動が少しずつ、改善にはつながっているようにも思うので、もがいた期間もムダではなかったのかなと思っているし、そう願いたい。
また、仕事とはちょっと離れるが、9月には職場の同僚とISUCONというコンテストに出ることになり、7月くらいから同僚と集まって練習をしたりもした。 チーム外の人と集まって何かをやること自体も楽しかったし、ここを通じて得られたものも多く、結果は出せなかったがとても良い経験だったと思う。
仕事以外
生活面では3月に結婚式があったり、6月にはお休みをいただいて新婚旅行に行ったりで、その間にはダンスのイベントに出させてもらったりと上半期はとにかくイベント盛りだくさんで慌ただしかったが、 とても充実して楽しい時間を過ごさせてもらえたように思う。
結婚式に関しては、転職して間もないこともあり現職の人をほとんど誘えなかったことや、どなたに祝辞をお願いするかなどタイミングの問題などもあり非常にアタマを悩ませた。 ただ結果として、色々な方々のご協力、支援のおかげもあり、自分たちの希望に沿う形で対応していただくことが出来、おかげさまで思い出深い素敵な1日を過ごす事ができた。 助けたいただいた方々には本当に頭が上がらない思いです。
あと2月頃には目黒雅叙園で前撮りをした。式が洋装なこともあり、和装ですてきな庭園があるこちらでは、場所はもちろんスタッフの方々も素晴らしく素敵な写真をたくさん取っていただいた。 すでに人気のスポットだが、あらためてここはすごくオススメしたいスポットだった。
今後
まずは仕事面でもっとバリューを出していけるようにしたい。 そのためにはエンジニアとしての技術力はもちろん、調整ごとやファシリテート力に難がある今の状態をもっと改善していく必要があると感じる。 前職での最後の方から、課題感は感じつつも出口が見えなかった状態から少しずつ進むべき方向が見えてきたような状況までにはなれたように感じているので、 少しでも先に進みつつ早い段階でここをうまくコントロール出来るようにしたい。
また、仕事面、プライベート面ともに新しいことをやるという経験が少なくなっているので、今月から1つずつでも「何か挑戦すること」と、今年もとわずかなので、今年の間「継続して取り組んでいくこと」というのを掲げて、 実践を試みているので、あと2ヶ月強走りきりつつ、少しでも手応え・成果を感じられるように過ごしたい。 とりあえず新しい挑戦として、今月は初心者向けのフットサルイベントに参加して、初めての経験と盛大な筋肉痛を得てきたが、とても楽しかったので今後も自分のペースで参加したいと思う。 来月と年末に何するかまだ決められていないので、まずはそこをかんがえて見るところから
また「継続して取り組んでいくこと」については、このブログなどでアウトプットとして成果を出せればとは思いつつも、インプットばかりでうまく進められていないので、まずは重い腰を上げてみるところから頑張ってみようと思う。
おわり
転職して1年が経過したので振り返り
昨年の10/15に約10年間働いた前職を退職し、10/16より現職に転職した。 人生で初の転職を経て1年間経ったので振り返ってみる。 思ったより長くなりそうなのでまずはpart1。2018年の振り返りから
前職と現職について
前職も現職もwebサービスのエンジニアということで同様の職種での転職になる。 担当サービスは、前職ではメール・FAXといった低レイヤーなところから、法人予約サービス、口コミシステムや航空券予約システムなど色々担当したが、 基本的にはオンライン旅行予約システムの開発だった。 現職では動画配信サービスの契約、決済周りなどを担当することになり、今まで未経験の新しい部分を担当させてもらうことになった。
また、規模も前職では約200人弱で国籍も様々なところから、約80人くらいでチームメンバーは全員、日本人と大きく環境が変わった。
2018/10〜12月
仕事面
最初の1ヶ月は今まで色々と環境が違いすぎてとりあえず戸惑いながら1年を過ごした記憶 メンバーや関係者、タスクの進め方、会議や決め事などの進行の仕方など、あらゆることが新しい環境で変わったので、 もちろん変化の大小はあるけれども、社内のツールの使い方や担当サービスのことなど分からないことだらけだった。 幸いにもチームのメンバーが親切に色々教えてくれたので、そこから少しずつ情報をキャッチアップできたのは良かった。
1箇所にどうしても10年近くとどまっていて、かつ他の環境を知らないと、「今までの常識=世間での常識」みたいに思い込んでしまっていたところも多く、 そこでの戸惑いや最初になるべく早くバリューを出そうという焦りなどから、年内はいろいろと迷惑かけてしまったり、ちょっと変な方向に暴走してしまったことも少なくなかったように思い、ここは今でも反省しているポイントの一つ。
組織・環境について
出来ればチームのメンバー全員やその他の人何人かとランチに行きたいと思いつつ、チーム内の数人しか出来なかったのは、未だに残念でならない。 ただ、週1で10人弱くらいでやっている技術ランチにうまく潜り込めたおかげで、顔はわかるという人も増えたり、普段、業務で関わらない人と話をする機会を得られたのは良かったし、それが今にも続いているのはありがたいことだったので、ここは良かったポイントだと思っている。
前職に比べて仕事の面では、手続きやフローと言ったものがほとんどなく、組織も基本フラットなため、自分の業務に集中できる時間が増えた。 また、今までは運用などに取られる時間がかなり多かったが、そういったこともリセットされて今までにないくらい開発に集中させてもらえる部分については転職してよかったなと思えた。
仕事以外
生活面など仕事以外の部分では、11月に入籍をして、入籍前からちょっとだけ進めていた結婚式についてちゃんと考えることに。 結果としては、翌年の3月に式を行うことになったので、早速打ち合わせやら何やらの準備を始めることになった。 この時点では、それほどやることが多いわけではないが、初めて知ることがいっぱいあって情報量が多く、そこが消化しきれず結構バタついていた気がする。
その他にも家の方の用事があったり、結婚式の準備としてダンスのレッスンに2人で通うようにしたりで、休日はだいたい何かしらの用事が入っている、という状態だったかと思う。 あと、式にどれくらい、どんな人を呼ぶか？2次会とかはどうするか？あたりで結構、話した気がする。
年末
年末に向けて、以前からあるサービスの担当にちょっと関わらせてもらう機会をもらうことになり、 いわゆるレガシーシステムをドメインナレッジなどから学んで、簡単な対応をしていくという機会もあり年末の仕事としてはそれでバタバタしていた。 ただ、今までさんざんレガシーシステムを経験してきた経験は少しばかり活かせたように思う一方、開発環境などでも思った以上にインフラ部分をサーバサイドエンジニアが触れなくてそのへんにはかなり戸惑ったし、そのあたりでもっと貢献したいと思っていただけに、そこについては残念だった。
そんなこんなで最初の3ヶ月を過ごしたが、 * ひたすら知識を入れつつ環境に少しでも早く慣れることが出来るように頑張った * 開発、特にコーディングに集中し今までとは良い意味で違う進め方が出来るようになってきた というのがこの間の所感でした
つづく
Architecture Night #2に参加してきた
Architecture Night #2
2019/10/18@サイバーエージェント
https://architecture-night.connpass.com/event/147171/
10/18（金）に「アーキテクチャナイト」というアーキテクチャについての各社の取り込みや思想についての発表があるイベントに参加してきました。 ここ最近は言語やツール、もしくはサービス・会社単位での勉強会のみならず、こういった設計やアーキテクチャをテーマとした勉強会が増えているように感じます。
1.WinTicket におけるリアルタイム性と高負荷を考慮したアーキテクチャ(CyberAgent 江頭さん)
メモ
- WinTicketとはオンラインの競輪投票サービス
- 購入・払い戻しのすべての責任を負う
- 常に最新の情報を取得・提供する必要がある = リアルタイム性が求められる
技術スタック
- golang
- k8s(GKE)
- envoy
- アンバサダーパターンを利用
- 当時はistioはアルファやベータ版が主だったのでenvoyを選択
- cloud spanner(DB)
- 3secでスケールアウトできる
fastly
映像周りは aws(elemental media service)
- 認証はfirebase
k8s
- 36個のマイクロサービスが動いている
- Gatewayパターン
- アンバサダーパターン
- どこかが落ちても継続して動かし続けたかったため
- オートスケールが出来るような構成
envoy
- サービスメッシュで可用性の向上
- Outlier detection
- 異常検知のこと
- ここではエラーが多い場合に自動で外す機能のことっぽい
- circuit breaker
- LB
- retry
- ロールアウト時に500エラーを返すなどが結構あるので、その場合にもenvoyがリトライやアクセスが行かないようにするなどハンドリングしてくれる
- Outlier detection
- ロギングなども envoy任せにしている
cloud spanner
- 下記の要件、リスクに対応できるようなものとしてcloud spannerを利用
- 金銭の取引があるのでトランザクション必須なため
- 購入できない場合は事業的損失が大きいというリスク
- レースの締め切り直前などは負荷が大きいというリスク
fastly
- リアルタイム性が求められるので利用
- Instant Purgeが決め手だった
- 導入した結果レイテンシをかなり抑えられている
- goのsingleflight という関数の多重呼び出しを抑制するメカに済でキャッシュミス時のオリジンへの負荷対策をしている
- キーに対して1つしか実行されない
- 参考. golang.org/x/sync/singleflightで重複呼び出しを排除する
サービス
- 払い戻しはキューイングしてワーカーで処理(cloud pub-sub)
- 30 万ユーザーに3分以内に払い戻し、という要件に対応するため
- 1000 ユーザー/sec で払い戻しできることを確認
- 当初の要件は満たせていないが、3 分で18万ユーザーなのでとりあえずここに着地
- 払い戻しはロックを取っている
- ロックでぶつかることはあまりない。ぶつかっても問題にはなっていない
- ミッションクリティカルな処理では UUIDv4 をリクエストに付加して多重実行を防いでいる
- ユーザ作成などは requests テーブルを用意して多重実行されても重複エラーになるようにしている
分散システムでのデザインパターン(?)
感想
お金が絡んでいることやリアルタイム性が重視されていることからか、要件もかなり高度なものが求められているように感じたが、 そこに対してGKEの機能やサービスをうまく活用して対応しているという印象を受けました。 分散システム、クラウドサービスをりゆおする場合のデザインパターンやWebの仕組みを踏まえた対応を、 サービスの環境を活用しながら着実にそして確実に実践することで、おそらく規模の大きいサービスをしっかり運用されているのだなと思い、 学ぶべきところ、見習うべきところがたくさんあるのではと感じたセッションでした。
2.秒間数千万メトリクスを裁く監視基盤のアーキテクチャ(LINE 株式会社 @dxhuy さん)
メモ
Observability
- 昔から使っているモニタリングプラットフォームを使っている
メトリクスのストレージを自前で開発している
- put(バッチ insert)とレンジを指定してデータポイントをクエリする 2 つの機能のみ
mysql や OpenTSDB では限界がきたので新しいストレージの開発の着手を始めた
- OpenTSDB でも書き込みは早いが、read に時間がかかる
- その他の OSS も試したが要件を満たせるものがなかった
要件
- 1ホスト辺り１万弱のメトリクスを保存。それを数十万ホスト
アーキテクチャ
- 機能ごとにマイクロサービスに分散
- 直近 28 時間のデータを全部メモリにのせる
grpc を利用 -> 早くはない。便利な機能が揃っている（クライアント LB など）
Redis や Memcached などは時系列データを効率的に圧縮するのが難しいため利用できない
圧縮には Facebook goriila delta-delta XOR アルゴリズムを利用(prometheus と同様)
再起動対応は、Write Ahead log（ディスクに書いてからメモリに保存）。ディスク保存のバックエンドは RocksDB
ネットワーク障害などによるロスを防ぐために、書き込み失敗した場合は kafka に書き込んで、DB に流している
1つのホストが死んでもデータロスを発生させない
- RAFT ベースでクラスターを構築
永続ストレージは cassandra を利用
- in-memory から GRPC で cassandra に転送
- 4h ごとにバッチ転送
表側は grafana だろうが prometheus だろうが http/udp などだいたい対応している
スケールイン／アウトによるリシャーディングは？
感想
LINEさんのような大規模なサービスでの社内プラットフォームに求められるレベルの高さとともに、 その高いレベルの要求に対して、理論や今まの経験に基づくナレッジやスキル、その仮説や仕組みに対しての検証などをフルに活用されて対応しているということを、 良い意味でまざまざと見せつけられたセッションでした。 理論やアルゴリズムやデータに関することなど、初めて聞く内容も多いセッションでしたが、すごく丁寧に、なぜ？どうして？を説明されていてとても興味深いセッションでした。
3.MirrativサーバのCleanArchitecture移行物語（株式会社ミラティブ 夏さん）
メモ
- Android/iOSはflux化を進めている
- webではCleanArchitecture を導入
- API仕様はblueprintを利用
- goでclean architcture
- まずは慣れている perl を元に Clean architecture での設計をして go に移植していく予定
方針
感想
レガシーシステムにどう対応していっているのかについてのセッションで、 自分もここまでアーキテクチャなどをしっかり考えた対応ではないものの、レガシーシステムの作り変えなどの経験があったので、 その経験などを振り返り、共感したところやなるほど、そうやっているのかと思うところなどがたくさんあり、思わずメモもあまり取れずでした・・ 自分たちの手に馴染んでいる言語で、まずどう作っていくかや検証などを進めつつ、新しい言語、アーキテクチャに段階的に移行していくという手法は、 こういったケースで非常に有効なのではと思い、今回、学びを得たポイントの一つでした。
懇親会
懇親会では、iOSエンジニアの方やSREとサーバサイドエンジニアを兼務さrている方などとお話をさせていただいたが、 みなアンテナが高く、守備範囲も広く、自分も、もっと経験や興味の幅を広げるなどをしてその辺りをキャッチアップできるようにならなくてはと感じました。
あと印象的だったのはサーバサイドはなるべく状態を持たないようにして、アーキテクチャと状態は疎にしていく、というのがベストプラクティスだと言われることが多い一方で、 フロントエンドやiOS/Andoroidアプリは状態を管理するためのフレームワークが需実していたり、そこをどう管理してくのかについての議論も多く、「状態」をうまく管理してくことが求められるので、その辺りに違いを感じるという話がありました。 言われて確かにと思った一方で、自分がメインとしている分野以外もキャッチアップしていくことで「見えてくるものや得られるもの」の重要さを感じた一幕でした。
総じて、得られたものが多く、参加できてよかったイベントでした。主催、運営の方々どうもありがとうございました！
