AWS DevDay Day2 参加レポート

はじめに

こんにちは、クラウド事業部の清水です。
6/23 AWS DevDay Day2に参加してきました。
どれも有益なセッションでした！

https://aws.amazon.com/jp/events/devday/japan/

入口

会場の様子

レガシーシステム、モダナイズへの道筋

・リライトを推奨。以下のメリットがある。
　・開発者目線：小さな成功体験を積めるのでのモチベーションを保ちやすい。
　・顧客目線：障害時影響範囲を最小化できる。
・既存の基盤から徐々に引きはがして新基盤に移行してくのがオススメ。
・データベースの移行は最後にしたほうが良さそう。
・Big Bang Rewire(既存システムを一から書き直すこと)はやめましょう。
・動作確認で直接手を動かす癖をやめましょう。
・「今日書いたコードは将来のレガシーコード」
・「Strangler Fig Pattern 何があっても小さくリリース」
・「道筋を案内できるリードエンジニアが必要」
・モダンアプリのコンサルティングをされている。
・スキルトランスファーも顧客満足度に影響する。

移行案件のハードルの高さを実感。
出来る限りミニマムに対応していくことが大事。

家で楽しむIOT

・マネージドサービスを使って極力障害を避けよう。
　→Iot GreenGrassでフロント受付をしてIoT Coreに連携
・センサーデータはCloudWatchでメトリクスとして登録可能
　→IoT製品のデモとしても使ってる
・電源が抜けていないかもCloudWatchで検知できるようにしている。
・SDカードよりもUSBブートがいいかもしれない。
　→SDカードが２年くらいで故障したこともある。
・pip installでサンプル実施が容易にできる。
・ペットの健康をモニタリングをトイレに体重計を組み込んで測ってみた。
　→猫砂や排せつの重さの検知が大変だった。
　→LINE Notifyで通知している。
　→家族が使い始めると障害が発生した時に怒られる。

参加したセッションで一番人が集まっていたような気がします。
そもそも自動化はロマンある。

シードスタートアップが自社デザインシステムをちいさくはじめてみた

・巨人の肩に乗る。＝既に出来ている優れているものを使おう。
　・デザインの一貫性が保ちやすい。
　・デザイン考える土台になる。エンジニアとデザイナーで共通認識を持てる。
・小さく始める＝時間の節約。

車輪の再開発はしない事を改めて認識しました。
スタートアップの話を未来を感じて面白い。

第一回似てるサービス使い分け大会

・AWSの機能数は3084を超えている。
・パラメータとシークレット管理
　→できる限り安く使いたならパラメータストアを
　→監査が必要ならシークレットマネージャ
　→パラメータを高度にデプロイしたいなら（実行中に変更を行いたい、ロールバック、スキームの検証）AppCofig ・キャッシュ
　→最小限のレイテンシーが要件の場合はElasticCashe
　→耐久性と高可用性が最優先の要件（キャッシュうが消えたら困る）の場合はAmazonMemoryDB for Redis
　　→レプリカを最大５台作れる。
　→データの移行がしたいならパラメータストアorパラメータストア（キャッシュがそもそもいらないなら）
　→消えたら困るデータがないならElasticCahce ・ワークフローオーケストレーション
　→依存関係を管理、トリガーを設定したいならしたいならAWS Glue
　→Apache AirFlowのワークロード管理ならMWAA
　　→既存のAirFlowがある場合や　　→動的なワークフローの定義も可能　→同期的、非同期的にも実装したいならStepFunction
　　→ビジュアル編集可能なStudio機能を提供している。
　　→最大10,000並列まで対応可能になった。
　　→さまざまなAWSサービスを組み合わせたい場合も有効
・バッチ処理
　→バッチ処理には定型業務、大規模計算処理の2種ある。
　→スケジューラやDockerコンテナイメージを基に作成して自動でスケールしたいならAWSBatch
　　→ジョブキューが必要だったらAWSBatch
　　→大規模計算を行いたいときも有効
　→タスクの作成や指定日時に1回だけ使いたいならEventBrgieScheduler
　　→at least one(少なくても一回実施を保証)
　　→単発で実行したい際も有効

機能数が多くてびっくり。
使い訳おおよそ当たっていたので勉強してて良かった。

テクノロジーで世界を変えられるのか　〜エンジニア出身経営者に聞く技術との向き合い方

・なぜ経営者に？
　→いいプロダクトをツールには良きチームが必要。組織文化が大事。それが面白い。
　→競技プログラミング(Atcoder)を布教したいから。
　→できることの範囲が広げられるから。
　→なぜAWSにキャリアチェンジした？
　　→エンタープライズの世界はDXが進んでない。DXを通して自分の可能性を広げていきたいと思ったから
　→テクノロジーで世界を変えるということ
　　→人間の進化はテクノロジーが促してきたと考えている。
　　→技術を生業する者として知らないは致命的。
　→テクノロジー自体は全く世界を変えない。
　　→無駄遣いもでる。
　　→テクノロジーは提供するプロダクトが世界を変えると思っている。
　　→テクノロジーはわかっていないといいプロダクトは作れない。
　→よくない開発は「言われた通りにやること」
　→一定の方向性を示すのがビジョン
　→人間の認知には限界があるので、自立的にメンバーを動かす設計が必要。
　→問題は設定されたら大半は解ける。
　→問題は設定されてないから解決できない。
　→エンタープライズだとふわふわした会議ばかりで決まらないので問題/課題設定は大切
→メンバーを楽しく仕事させるのが出来る管理職
→ググれば解決できることの価値は低い。
→知識や経験で創造できるものに価値がある。
　→学び続けることにより自分を風の吹いている場所に居続けることができる。