July Tech Festa

techfesta.connpass.com

イベント自体は知っていましたが初参加。

感想

• インフラエンジニアの勉強会（Peatixかどこかに記載あったはず）だと思っていますが、キャリア一般とかフロントエンドとか範囲広いのですね。
• 資料を事前・事後に（SpeakerDeckなどで）共有してくれる方が多いのが、凄いく嬉しいです
  特に、オンラインイベントだと文字が潰れて見にくい事もあるので。
• C4の「凡人エンジニアの生存戦略」が特に印象に残っています
  （ちょうど自分も同じような焦燥感を‥）

運営、登壇者の皆様お疲れ様でした

TrackC1 テクニカルサポートエンジニアという働き方 - 技術と英語で立ち向かうOSSとエンタープライズの世界

しがないラジオでお話聞いたことがあるお方。

• ひよこ大佐の経歴（国内サポートエンジニアー>SES->レッドハット）
• これまでのスキルを転職で活かす。特にスキルの掛け算大事
• スキルを増やすには、知的好奇心とキャリアに関するオーナーシップ
• ひよこ大佐さんの仕事（テクニカルサポートエンジニア、TSE）の話
  （関連する技術の話も多い）
• 英語の話（レッドハットのTSEは英語必須。チーム・お客さんともに）
• 広範な知識がいるので、SIer時代に色々触っていたのが生きている
• RedHatとOSSとの関わり
• トラブルシューティングの方針（重要度、再現、似たような事例‥）
• 切り分け大事
• ログ大事。ちゃんと読もう

 

TrackG2 プロジェクトチームで取り組む実践的なクラウドコスト最適化

 Sansan DSOCの大澤さん。

• Cloud Cost Optimization Engineer（という肩書らしい）
• AWSコスト最適化の同人書いたよ。商業誌も出るよ
• SansanとDSOCの紹介
• コスト最適化の歴史
• システム規模以上にコスト増大
• アカウントに複数システムあり、コスト追跡が難しかった
• 予測困難
• トップダウンでプロジェクトチーム
• AWS Well-Architected Frameworkに沿っている
  ↑おすすめらしい
• やったこと
• リソースにコスト配分タグ（チーム単位）付けて、追跡出来るように
• タグ付け大変なのでAWS Lambdaで自動付与（名前から推測。ただし間違う部分は手動）
• AWSアカウント構造の話。素直にやるならマスターアカウントが必要で大変
• Cost and Usage Report(CUR)＋Athenaで対応
• redashでAWS/GCPのコストの両方を可視化
• TCO（総保有コスト）と費用対効果を意識して、優先度付け
• 事例1：DynamoDBとの通信がNAT Gateway経由になっていた
• 事例2：DynamoDBをキャパシティモードからプロビジョニングモード
• 事例3：Auroraのストレージ容量の削減（自動でストレージ容量増えるが、使用量減っても容量減らない）
• 事例4：Glueジョブの見直し（間隔、不要なジョブの削除）
• コスト最適化の評価は削減額で評価（難しそう‥）
  使用量や名刺一枚のデータ化に関するコスト
• コスト最適化スキルは（パブリッククラウドに関する）エンジニアには必須スキル
• ↑クラウドに対するりかい、自分たちのシステムに関する理解が必要。

TrackF3 バックエンドエンジニアの私がお勧めするSPAフロントエンド開発環境

ハートビーツの渡辺さん。

• バックエンドの人がフロントにキャッチアップするの辛いよね
• 自分用のボイラープレート作っておいて、作り回しているよ
• React/MobX/TypeScript/MaterialUIあたり

TrackC4 凡人エンジニアの生存戦略

ソフトバンクの高市さん。SonarQube本の著者。

• プログラミング超好きというわけではなく、 若手キャリアの焦燥感を感じていた
• まつもとゆきひろの「プログラマー勉強会」
• 自分を知ってもらうことで価値があがる
  （観測可能な成果）
• 締め切り駆動で公開
• 発表するために調べるので、どんどん知見が広がる
• Trellloつかって定期的に振り返り
• 努力を習慣化するために頑張る
• 習慣化する数を少なく、それぞれの目標を小さく
• 根性論より人間の習性に従う
• 他人と比べない
• 短所より長所を見る
• 後知恵バイアスを気にしない

（私もまつもとさんの勉強会見て、Twitter始めたりしました）

TrackG5 クラウド時代の今こそ！理解して拡げる分散システムの基礎知識

 こば（@tzkb）さん。Fukabori.fmとかQiitaとかでお見かけ。

• DXとかクラウド
• マイクロサービスの話
• DBを共有していると拡張性などに影響（するのでマイクロサービスと言いたくない）
• かといって、DBを分割すると分散トランザクションが生じてくる
• マイクロサービスでトランザクションを実行するSagaパターン
• それぞれのサービスがローカルトランザクションし、問題があったらそれぞれロールバック
• そのままではACIDのうちIsolationが満たせない（ローカルトランザクションされたら覗ける）
• 分散・マイクロサービスにしても、スケールするとは限らない
• 特にステートフルなDBが危ない
• 対応1)single leaderのreadのreplication
  （writeがスケールしない。非同期な同期が耐障害性が低い）
• 対応2)Multi-Leader(Viess, Oracle RACなど)
• 地理的な拡張性
• 東京大阪で20msくらい、海外まで行くと100ms程度かかる
• 量的・地理的な拡張性のあるデータベースの例
  Spanner、Cockroach、Yugabyte、TiDBなど
• シャード（テーブルの分割）毎にリーダーがいる