20260110_オンプレ思考からクラウドネイティブ思考への転換レシピ

Transcript

1. オンプレ思考からクラウドネイティブ思考への 転換レシピ 下坂 真里亜 ・ 加藤 寛士 ～AI活用のスパイスを添えて～
2. 自己紹介 下坂 真里亜 （しもさか まりあ） 所属：JAWS-UG金沢 勤務地：石川県 エンジニア歴：5年目 好きなこと ゲーム（モンハン）、旅行、チェロ 加藤 寛士 （かとう ひろし） 三重県在住 JAWS-UG名古屋運営 クラウドエンジニア @Hircha12 BuriKaigi初参加 BuriKaigi初参加
3. 身近にアーキテクチャをすぐに出してくれる スーパーマンのような人はいませんか？ 何を考えながらアーキテクチャを作っているのでしょうか このセッションについて アーキテクチャを考えるための思考法の一例についてお話しします
4. ブーリー 分クッキング 10 このセッションについて
5. ブーリー 分クッキング 10 アプリケーションサーバ Web アプリ ファイル 受信 API バッチ 処理 データベース ユーザ 商品 在庫 注文 決済 本日の料理 クラウドらしいアーキテクチャに 仕上げていきます オンプレ思考から クラウドネイティブ思考へ 材料） アプリケーションサーバ：一式 機能・・・Webアプリ、API、 ファイル受信、バッチ処理 データベース：一式 属性・・・ユーザ、商品、在庫、 注文、決済 recipe
6. ブーリー 分クッキング 10 まず、どのように調理しますか？ 本日の料理 アプリケーションサーバ Webアプリ ファイル 受信 API バッチ処理 データベース ユーザ 商品 在庫 注文 決済
7. ブーリー 分クッキング 10 まず、どのように調理しますか？ EC2 RDS 本日の料理 アプリケーションサーバ Webアプリ ファイル 受信 API バッチ処理 データベース ユーザ 商品 在庫 注文 決済
8. ブーリー 分クッキング 10 まず、どのように調理しますか？ EC2 RDS 本日の料理 これでも動く、けどクラウドのメリットを受けられません アプリケーションサーバ Webアプリ ファイル 受信 API バッチ処理 データベース ユーザ 商品 在庫 注文 決済
9. ブーリー 分クッキング 10 まず、どのように調理しますか？ EC2 RDS 本日の料理 これでも動く、けどクラウドのメリットを受けられません アプリケーションサーバ Webアプリ ファイル 受信 API バッチ処理 データベース ユーザ 商品 在庫 注文 決済 食べられないことはない ・・・ けど、美味しくない
10. ブーリー 分クッキング 10 本日の料理 分解して、考えられる 状態にする 切る 味付け 煮込み 盛り付け 選択とトレードオフ を決める 材料と味付けを合わせ 構成を組み立てる システムを商用利用 できるようにする 美味しくするには、きちんと調理をして、クラウドにのせていく必要があります
11. ブーリー 分クッキング 10 本日の料理 分解して、考えられる 状態にする 切る 味付け 煮込み 盛り付け 選択とトレードオフ を決める 材料と味付けを合わせ 構成を組み立てる システムを商用利用 できるようにする セキュリティ＝厨房の衛生基準 特定の工程ではなく、すべてに共通して考えるべきもの、大前提です
12. ブーリー 分クッキング 10 ブーリー 分クッキング 10 「切る」とは、選択肢を作ること 切らないと、選べません • サービスの選定の前にやる • 比較・選択ができる状態にする Step1 切る
13. ブーリー 分クッキング 10 食材を分解して、考えられる状態にします Step1 切る アプリケーションサーバ Webアプリ ファイル 受信 API バッチ 処理 データベース ユーザ 商品 在庫 注文 決済
14. ブーリー 分クッキング 10 アプリケーションサーバ Webアプリ ファイル受信 API バッチ処理 アプリケーションを切るときのPOINT 依存関係 時間 責務と役割 Step1 切る この3つの観点で切って問題がないかを確認します
15. ブーリー 分クッキング 10 アプリケーションサーバ Webアプリ ファイル受信 API バッチ処理 切るときのPOINT 依存関係 時間 責務と役割 ファイル受信 バッチ処理 Step1 切る ファイル受信と バッチ処理は 簡単に切れそう！ 繋がりが複雑で 切りにくそうだけど・・・
16. ブーリー 分クッキング 10 Webアプリ API Step1 切る 切るときのPOINT 依存関係 時間 責務と役割 同期で呼び出されてて、 時間軸でも切りにくそう 非同期で実行してるから、 時間軸でも切れそう！ アプリケーションサーバ ファイル受信 バッチ処理
17. ブーリー 分クッキング 10 データベース 入力 業務 通知 Step1 切る 切るときのPOINT 依存関係 時間 責務と役割 Webアプリ API アプリケーションサーバ ファイル受信 バッチ処理 エ ン ド ポ イ ン ト サーバからエンドポイントを 外せるといいな エンドポイントは 全体でひとつがいい
18. ブーリー 分クッキング 10 アプリケーションサーバ Webアプリ 画面 Step1 切る API ビジネスロジック 認証認可 更新 参照 画面 ビジネス ロジック 認証認可 参照 更新 細かく見ると、 もっと切り出せる 部分がありそう 切れるかどうかは 全体の仕組みで 変わってきそう・・・ 切るときのPOINT 依存関係 時間 責務と役割
19. ブーリー 分クッキング 10 Step1 切る アプリケーションサーバ Webアプリ ファイル受信 API バッチ処理 アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期
20. ブーリー 分クッキング 10 Step1 切る データベース ユーザ 商品 在庫 注文 決済 データベースを切るときのPOINT 時間 データの特徴 この2つの観点で切って問題がないかを確認します
21. ブーリー 分クッキング 10 データベース 参照系 更新系 200ミリ秒以内の レスポンス Step1 切る 参照と更新でDBリソース を奪いあうので切り分け られるかな？ 切るときのPOINT 時間 データの特徴
22. ブーリー 分クッキング 10 キャッシュ・ リードレプリカ 参照系 更新系 200ミリ秒以内の レスポンス Step1 切る 切るときのPOINT 時間 データの特徴 データベース 更新の中でも一部は 時間をかけても 大丈夫そうだ
23. ブーリー 分クッキング 10 キャッシュ・ リードレプリカ 参照系 更新系 200ミリ秒以内の レスポンス Step1 切る 切るときのPOINT 時間 データの特徴 データベース 遅延OK キュー 更新系
24. ブーリー 分クッキング 10 データベース 整合性が 必要 大量の データ 処理速度 Step1 切る オンプレでは1つのDBに詰め込む特徴があるが、 クラウドではそれぞれの特徴を持ったDBを使用することができる 特徴ごとに使用するDBを変えていけると、クラウドのおいしさがあがる 切るときのPOINT 時間 データの特徴
25. ブーリー 分クッキング 10 整合性重視の データベース 整合性が 必要 大量の データ 処理速度 Step1 切る オンプレでは1つのDBに詰め込む特徴があるが、 クラウドではそれぞれの特徴を持ったDBを使用することができる 特徴ごとに使用するDBを変えていけると、クラウドのおいしさがあがる 切るときのPOINT 時間 データの特徴 拡張性重視の データベース 速度重視の データベース 切れるかどうかは 全体の仕組みで 変わってきそう・・・
26. ブーリー 分クッキング 10 Step1 切る キャッシュ・ リードレプリカ （参照） データベース （更新）
27. ブーリー 分クッキング 10 Step1 切る データベース （更新） キャッシュ・ リードレプリカ （参照） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期
28. ブーリー 分クッキング 10 ブーリー 分クッキング 10 アーキテクチャに正解はない、あるのは「一番の妥協点」 味付け＝トレードオフ Step2 味付け コスト 運用負荷 納期 性能 可用性 全ての味がする料理は存在しない 優先させる味と、犠牲にする味を決める
29. ブーリー 分クッキング 10 Step2 味付け コスト薄味 犠牲にしたもの 高度な機能、拡張性、可用性 運用さっぱり 犠牲にしたもの 初期開発速度 納期時短 犠牲にしたもの 運用コスト、技術的負債
30. ブーリー 分クッキング 10 コスト薄味 Step2 味付け 運用さっぱり 切った材料 選択した味付け 料理の途中で味付けを変更はできません（させられることもあるけど・・・） しっかりと考えて決定します
31. ブーリー 分クッキング 10 Step3 煮込み 「煮込み」では、選んだ味付けを、 最後まで破綻しない構成として成立させます ✓ 切った材料に選んだ味付け（トレードオフ）を反映し、 処理方式・責務・失敗時の動きまで一貫した構成に組み立てていきます • 同期か？ 非同期か？ • どこまでを自動化し、どこを諦めるか？ 判断の整合性を取る工程です
32. ブーリー 分クッキング 10 Step3 煮込み コ ス ト 運 用
33. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） キャッシュ・ リードレプリカ （参照） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期
34. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照）
35. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） Lambdaで 運用さっぱり SQSで非同期 Ｓ３でイベント駆動 に、非同期化 リードレプリカで参 照と更新を分離
36. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 参照 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 運用が薄味にで きていない
37. ブーリー 分クッキング 10 Step3 煮込み
38. ブーリー 分クッキング 10 Step3 煮込み 画面 認証認可 参照
39. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ 画面 API ビジネスロジック 認証認可 更新 API（参照） エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照）
40. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ API ビジネスロジック 更新 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 認証認可 画面 API（参照） ク ラ イ ア ン ト
41. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ API ビジネスロジック 更新 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 認証認可 画面 API（参照） ク ラ イ ア ン ト フロントエンドが 守られていない
42. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ API ビジネスロジック 更新 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 認証認可 画面 API（参照） ク ラ イ ア ン ト フ ロ ン ト エ ン ド
43. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ API ビジネスロジック 更新 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 認証認可 画面 API（参照） ク ラ イ ア ン ト フ ロ ン ト エ ン ド データの特徴でDB を分けるとコストが 変わるかも
44. ブーリー 分クッキング 10 Step3 煮込み
45. ブーリー 分クッキング 10 Step3 煮込み データベース （更新） アプリケーションサーバ Webアプリ API ビジネスロジック 更新 エ ン ド ポ イ ン ト ファイル受信 バッチ処理 非同期 キャッシュ・ リードレプリカ （参照） 認証認可 画面 API（参照） ク ラ イ ア ン ト フ ロ ン ト エ ン ド 高パフォーマンスの データベース
46. ブーリー 分クッキング 10 Step3 煮込み リードレプリカ 参照 ファイル受信 バッチ処理 認証認可 静的コンテンツ Webアプリ
47. ブーリー 分クッキング 10 リードレプリカ 参照 ファイル受信 バッチ処理 認証認可 静的コンテンツ Webアプリ Step3 煮込み 吹きこぼれ 処理に失敗！ エラーが起きる前提で、成立する設計 エラーが発生し、処理が止まる箇所がないか 吹きこぼれ DBが応答しなく なった！
48. ブーリー 分クッキング 10 Step3 煮込み DLQに保存 リードレプリカ 参照 ファイル受信 バッチ処理 認証認可 静的コンテンツ Webアプリ エクスポネンシャル バックオフで、間隔 をあけてアクセス エラーが起きる前提で、成立する設計 エラーが発生し、処理が止まる箇所がないか
49. ブーリー 分クッキング 10 Step3 煮込み リードレプリカ 参照 ファイル受信 バッチ処理 認証認可 静的コンテンツ Webアプリ
50. ブーリー 分クッキング 10 Step4 盛り付け • 煮込んだだけでは、まだ料理は提供できません • 商用システムでは、「障害が発生する前提」「人が入れ替わる前提」でも 安心して出し続けられる状態が求められます 「盛り付け」は、料理のおいしさを 「維持し続ける」ための工程 運用 人が変わっても回るか 監視 異常に気づけるか 障害対応 止まっても復帰できるか バックアップ 取り返しがつくか
51. ブーリー 分クッキング 10 Step4 盛り付け バックアップ バックアップ 監視 アラーム SLO 通知
52. 完成品
53. 切る 味付け 煮込み 盛り付け • 切り方で、責任の曖昧な処理を生んでいないか • トレードオフの結果、取り返しのつかないものを残していないか • 1つ壊れたとき、影響はどこまで閉じ込められるか • 担当者が変わっても、同じ安全水準で運用できるか すべての判断の裏側で
54. 振り返り 「切って」、「迷って」、「捨てて」、「妥協点を選ぶ」 これが、クラウドネイティブな思考です 分解して、考えられる 状態にする 切る 味付け 煮込み 盛り付け 選択とトレードオフ を決める 材料と味付けを合わせ 構成を組み立てる システムを商用利用 できるようにする
55. 思考のレシピを、AIと一緒に回してみる 〜AIを「思考の副料理長」として使いこなそう〜
56. なぜ、上級者の判断は「魔法」に見えるのか？ 複雑な要件に対し、上級者は即座に 「この構成がいい」と答えを出す 初学者にとって、それは直感や経験則 という名の、魔法のように見える
57. 「魔法」の正体は、膨大な思考の痕跡 アーキテクチャ設計とは、正解を探し出すのではなく、 もっとも最適な妥協点を選択するプロセスである
58. 上級者は、頭の中で何をしているのか？ ひらめきではなく、思考の往復運動 ① 前提を疑う ② 制約を洗い出す ③ 選択肢を並べる ④ 捨てた理由を言語化する ⑤ 妥協点に名前をつける • 本当にこの要件は固定か？ • 暗黙の前提が紛れ込んでいないか？ • 「一番いい構成」は考えていない • 性格の違う複数案を並べている • なぜ◯◯を捨てたのか • どのリスクを受け入れたのか • 技術制約 • 期限・コスト・運用制約 • 将来の変化耐性 • 「これは現実的に一番マシ」 • 「このリスクなら責任を持てる」
59. 上級者は、頭の中で何をしているのか？ 思考量が増えるほど、根拠のある判断に辿り着ける ① 前提を疑う ② 制約を洗い出す ③ 選択肢を並べる ④ 捨てた理由を言語化する ⑤ 妥協点に名前をつける • 本当にこの要件は固定か？ • 暗黙の前提が紛れ込んでいないか？ • 「一番いい構成」は考えていない • 性格の違う複数案を並べている • 技術制約 • 期限・コスト・運用制約 • 将来の変化耐性 • 「これは現実的に一番マシ」 • 「このリスクなら責任を持てる」 思考量を 増やす 思考量を 増やす • なぜ◯◯を捨てたのか • どのリスクを受け入れたのか
60. AIを「答えの自動販売機」から「思考の副料理長」へ AIに唯一の正解を求めない (アーキテクチャ設計に唯一の正解はない) AIを、人間の思考を補助し、 試行錯誤の回数を劇的に増やすための パートナー(副料理長)として活用する
61. 隠し味③ 公開試食 ・設計の穴の炙り出し 隠し味① 味のバランスシート ・トレードオフの可視化 隠し味② 逆算レシピ ・暗黙的な制約の言語化 副料理長(AI)を使いこなすための「3つの隠し味」
62. 隠し味① トレードオフを味のバランスシートにする 正解の一品を、AIに結論付けさせるのではなく、 コスト・運用・納期など、バランスの異なる いくつかの試作品を出させる 何を捨てて、何を得るのかを言語化し、 納得して選択する 重要なのは、AIに、各品で捨てた材料を 明確に表現させること
63. 隠し味② 「この料理、何が入ってる？」 レシピを逆算 既存のアーキテクチャ図は、「完成料理の写真」であり、本当に知りたいのは、 その背景にある隠されたレシピ AIに完成料理を味見させて、隠し材料を推理させる なぜ、S3ではなく、高価なFSxが採用されているのだろう？
64. 隠し味③ AI料理長の「公開試食レビュー」 自身の視点だけでは気づきにくい味の違いを、AIによる辛口レビューで炙り出す 自分が得意ではない要件に着目させると効果的 AIに優しいコメントは求めない 厳しく欠点を指摘して、と明確に指示をする ＜プロンプト例＞ このアーキテクチャを、シニアアーキテクトとしてレビューしてください 特に、下記について、具体的に指摘してください ・単一障害点(SPOF) ・スケーラビリティのボトルネック ・運用コストが予期せず増大するリスク
65. よくある厨房の失敗 AIは万能ではない、使い方を誤ると料理が台無しになる・・・ 失敗③ 的外れな 辛口コメント 失敗① 材料不足なのに 料理だけ立派 失敗② 味見せずに 出してしまい、 大事故
66. 失敗① 材料が足りないのに料理だけ立派 AIは、前提条件が不足していても、もっともらしい答えを作成してしまう 不足している材料を、勝手に創作されてしまい、大きく方向性が逸れてしまう 前提条件を、先に揃える AIに、不明確なことがあれば、確認するように伝える
67. 失敗② 味見せずに出してしまい、大事故 AIの出力を鵜呑みにし、検証せずに採用してしまう 料理の試作品を、味見もしないでお客に提供するようなものである AIの出力は試作品と心得て、必ず人が味見(検証)する
68. 失敗③ 的外れな辛口コメント 何が重要であるかを、適切に伝えないと AIのコメントが的外れになる ⇨ 「パフォーマンスを最重要」な設計に 「コストが高い」と指摘するようなもの AIにレビューさせる際には、評価軸を明確にする ⇨ 評価軸の作成も、AIに手伝ってもらうのもアリ
69. AIは、思考を加速させる そして、最高の一皿を決めるのは、料理長である私たちです 副料理長(AI)を使いこなせる料理長だけが、 次の厨房に立てる
70. ご清聴ありがとうございました！