Beyond the twelve-factor app ご紹介

Transcript

1. クラウドネイティブの旅に出よう: Beyond the Twelve-Factor App 解説 IBM Tech/Developer Dojo 2023/07/20 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 1
2. 本⽇の⽬標 “Beyond the Twelve-Factor App” とは何か “12 Factor App” とは何が違うのか が、なんとなく分かり、語れるようになる︕ Copyright ©2023 NS Solutions Corporation, IBM Corporation. 2
3. 本⽇のアジェンダ 1. オープニング 2. Beyond the Twelve-Factor App のご紹介 3. QA・クロージング Copyright ©2023 NS Solutions Corporation, IBM Corporation. 3
4. はじめに 当イベントは⽇本IBMおよび⽇鉄ソリューションズの有志エンジニアによって企画された勉強会です。 クラウドネイティブやマイクロサービスなどのテーマを中⼼に、今後も⾊々な勉強会・イベントを開催する予定です。 本勉強会の内容は、エンジニア個⼈の⾒解であり、所属する企業の公式⾒解ではありません。 セッション中はマイクミュートでの参加にご協⼒お願いします。 本イベントは録画してアーカイブ公開する予定ですので、その点ご了承ください。 本発表で利⽤している製品の名称およびロゴは下記の個⼈、組織または企業の商標となります。 Docker は、⽶国および/またはその他の国における Docker, Inc. の商標または登録商標です。 Javaは、Oracle、その⼦会社及び関連会社の⽶国及びその他の国における登録商標です。 NS（ロゴ）、NSSOL、NS Solutions は、⽇鉄ソリューションズ株式会社の登録商標です。 その他本⽂記載の会社名及び製品名は、それぞれ各社の商標⼜は登録商標です。 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 4
5. ⾃⼰紹介 ＜所属＞ ⽇本IBM カスタマーサクセスマネージャー <経歴> 2016年に⽇本IBMシステムズ・エンジニアリングに⼊社 スクラムマスターとしてweb/モバイルアプリ開発を経験 し、2021年からIBMでカスタマーサクセスマネージャー <趣味など> ペットの猫と遊ぶ、ハッカソン参加 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 佐川 洵貴（さがわ じゅんき）
6. ⾃⼰紹介 ＜所属＞ ⽇鉄ソリューションズ システム研究開発センター <経歴> 2019 年に⽇鉄ソリューションズに新卒⼊社。 スクラムでのクラウドネイティブ案件においてアーキテ クト兼開発者を経験。 <趣味など> ⽇本酒、（⾮電源含む）ゲーム、ごま⾖腐 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 喜多 司（きた つかさ）
7. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 望⽉ 雄登（もちづき ゆうと） ＜所属＞ ⽇鉄ソリューションズ システム研究開発センター <経歴> 2022 年に⽇鉄ソリューションズに新卒⼊社。 BFF(Backend For Frontend)構成全体の監視を導⼊する 案件を担当。 <趣味など> アニメ、ゲーム、将棋 ⾃⼰紹介
8. 本⽇のアジェンダ 1. オープニング 2. Beyond the Twelve-Factor App のご紹介 3. QA・クロージング Copyright ©2023 NS Solutions Corporation, IBM Corporation. 8
9. Beyond the Twelve-Factor App 概要 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 9 12 Factor App (2012) 次のような Web アプリケーションにおけるインフラ観点でのベストプラクティス セットアップ⾃動化のために宣⾔的フォーマットを使⽤ 依存関係を明確化し移植性を⾼める クラウドに適する 環境間の差異をなくして継続的デプロイを可能にする スケールアップが容易 Beyond the Twelve-Factor App (2016) クラウドネイティブ向けに内容更新と項⽬追加をしたもの
10. 進め⽅ 各章の説明の流れ
11. Chapter 6 Logs （Order 11 → 6） You should consider the aggregation, processing, and storage of logs as a nonfunctional requirement that is satisfied not by your application, but by your cloud provider or some other tool suite running in cooperation with your platform. You can use tools like the ELK stack (ElasticSearch, Logstash, and Kibana), Splunk, Sumologic, or any number of other tools to capture and analyze your log emissions. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 11 12 Factor App での優先順位が Beyond the Twelve-Factor App で どう変わったか Beyond the Twelve-Factor App にある印象的だった、 あるいは結論的な⽂章の引⽤。 次のスライドで解説するので、 熱⼼に読まなくて⼤丈夫
12. ログ 解説とポイント 「ログの集約、処理、保存はアプリケーションソースコードで気にすることなく、クラウドプロバ イダやその他関係するツール群の機能に任せる」とある あくまで「集約から」なので、「どんなログを stdout/stderr に出⼒するか」はアプリケーショ ン開発者がちゃんと考えないといけない ログのフォーマットや、バックエンドサービスとの通信時のメッセージは業務ロジックとは直接 関係がないため、標準化の動きがある • OpenTelemetry Copyright ©2023 NS Solutions Corporation, IBM Corporation. 12 「」で囲われている⽂章が Beyond the Twelve-Factor App に記載されていた内容の 和訳あるいは意訳 Beyond the Twelve-Factor App に 直接記載されてはいないが、内容の解 釈にあたって発表者が補⾜している ポイントには指マーク
13. ログ 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 13 近年、可観測性への注⽬が⾼まっている。たとえば APM（Application Monitoring）製品 は RCA（Root Cause Analysis）や SLI/SLO 測定、エラーバジェットのバーンレートに基 づくオンコールなど多機能化していることから、優先順位が上がったことに対して違和感はない 12 Factor App では、APM などを使うのはあくまで以下のようなことを確認するため、と記載さ れている • 過去ログ • 傾向分析 • アラート 発表者の感想や考察 • The 12 Factor App から何がどのようにどうして変わったのか • Beyond the Twelve-Factor App に賛成なのか、反対なのか • 発表を聞いてくださっている皆さんにどんなアクションをしてほしいのか • …etc
14. 担当 Chapter 1-5 : 望⽉ Chapter 6-10 : 喜多 Chapter 11-15 : 佐川
15. Chapter 1 One Codebase, One Application （Order 1 → 1） One codebase tracked in revision control, many deploys. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 15
16. One Codebase, One Application 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 16 コードベースとアプリケーションが多対1である例 「1つのアプリが複数のソースコードリポジトリで構成されている」 「密結合な共同作業者がいる」 アプリケーションとコードベースが多対1である例 「1つのコードベースに複数の起動スクリプトがある」 「1つのコードベースを複数のチームが管理している」 コードベースとは、同じルートを共有するソースコードリポジトリ
17. One Codebase, One Application 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 17 「コードベースとアプリケーションが1対1の関係」 「コードベースはソースコードリポジトリでバージョン管理される」 「チームごとにマイクロサービスで分割すると良い (コンウェイの法則による)」 「複数のアプリが同じ機能を持つ場合、それぞれのコードベースは共有ライブ ラリという別のコードベースを参照する」
18. One Codebase, One Application 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 18 守られていない場合、アプリが密結合であるので、 マイクロサービスとして独⽴した機能にするのが難しい (モノリスと同等) 依存関係を考慮した開発が必要 問題発⽣時の原因特定が難しい テストが複雑になる → クライドネイティブな構成に必須 (複雑化により依存関係の問題が深刻) 依存関係の排除の徹底が、本⽂書の⼤きな⽅針の1つだと思う
19. Chapter 2 API First （NEW） API first means that what you are building is an API to be consumed by client applications and services. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 19
20. API First 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 20 「構築しているもの = クライアントやサービスによって消費されるAPI Web、モバイル、UI等に関わらず、実際にはAPIの消費者に過ぎない」 「最初にAPIを設計することで、ステークホルダーとディスカッションを進められる」 「APIファーストの開発をサポートするツールや標準化が進んでいる (API Blueprintと呼ばれるマークダウンのようなAPI仕様の標準フォーマット、ツールスイートApiary 等)」 「迅速なプロトタイピングを可能にし、CI/CDパイプラインを容易にする」
21. API First 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 21 マイクロサービスでは、処理をブラックボックス化し、使い⽅(インタフェース)の みを公開する エコシステムは内部処理に興味がないので、APIの仕様が最も重要で、 API設計を最初に⾏うのは⾃然なこと
22. Chapter 3 Dependency Management （Order 2 → 3） Properly managing your applicationʼs dependencies is all about the concept of repeatable deployments. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 22
23. Dependency Management 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 23 「開発者が依存関係を宣⾔する。その依存関係が満たされるようにする責 任をツールに負わせることができる」 「依存関係が管理されていなければ、頻繁な開発の妨げとなる」「ほとんど のプログラミング⾔語に依存関係を管理する機能がある (Maven, Gradle (Java), NuGet (.NET), Bundler (Ruby), godeps (Go))」
24. Dependency Management 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 24 ライブラリバージョンなどの依存関係管理をしていない場合、エラーの解決が ⾮常に⼤変 (時間の無駄、成⻑につながらない) ⼤量のエコシステムや依存関係が存在するクラウドネイティブな構成では、 ⼈間が管理できないので必須
25. Chapter 4 Design, Build, Release, Run （Order 5 → 4） The key takeaway from this chapter is that each of the following deployment stages is isolated and occurs separately. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 25
26. Design, Build, Release, Run 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 26 「設計: ⼩さな機能の設計」 「ビルド: 複数環境にリリース可能な(環境⾮依存の)バイナリを⽣成 (理想はCIサーバで実⾏)」 「リリース: 実⾏バイナリと環境設定をあわせ、実⾏可能な状態にする (不変かつ⼀意)」 「実⾏: クラウドプロバイダが実⾏」
27. Design, Build, Release, Run 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 27 単に実現⼿段の段階のことを⾔っている 「Build, Release」は、「Configuration, Credentials, and Code」の分離 を実現するための⽅法 アジャイル開発でもウォーターフォールほどではないが設計は必要であり、 処理の無駄と管理の⼿間を省くために環境⾮依存部分のみを抽出し、 頻繁に変更される共通部分と変化の⼩さい環境ごとの差異を融合して、 実⾏する。クラウドでは、スケール、耐障害性、ログ管理、...を任せられる
28. Chapter 5 Configuration, Credentials, and Code （Order 3 → 5） Treat configuration, credentials, and code as volatile substances that explode when combined. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 28
29. Configuration, Credentials, and Code 解説とポイント Copyright ©2023 NS Solutions Corporation, IBM Corporation. 29 「設定、認証、コードは分離する」 「設定とは、デプロイメント間のすべての差異のこと」 「認証とコードが分離されている状態は、オープンソースとして公開できる状態」 「設定には環境変数またはクラウドサービスを使う (⾔語固有の設定ファイルを使わない。プロパティファイル (Java), XML (.NET), YAML (他))」 デプロイメントとは、リリースに加えて環境の状態まで含めた⾔葉
30. Configuration, Credentials, and Code 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 30 サービス間だけでなく、リリース内の依存関係を分離するということ 守られていない場合、以下のような問題が想定される 環境変数が変わるごとにコード変更とビルドが必要 1つのアプリに複数のコードベースが存在し、同じ内容の変更箇所が複数になる 初めからこれを意識していない場合、後からの修正は⾮常に⼤変なので、 開発時には、依存関係の分離を常に意識すべき
31. Chapter 6 Logs （Order 11 → 6） You should consider the aggregation, processing, and storage of logs as a nonfunctional requirement that is satisfied not by your application, but by your cloud provider or some other tool suite running in cooperation with your platform. You can use tools like the ELK stack (ElasticSearch, Logstash, and Kibana), Splunk, Sumologic, or any number of other tools to capture and analyze your log emissions. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 31
32. ログ 解説とポイント 「ログの集約、処理、保存はアプリケーションソースコードで気にすることなく、クラウドプロバ イダやその他関係するツール群の機能に任せる」 あくまで「集約から」なので、「どんなログを stdout/stderr に出⼒するか」はアプリケーショ ン開発者がちゃんと考えないといけない ログのフォーマットや、バックエンドサービスとの通信時のメッセージは業務ロジックとは直接 関係がないため、標準化の動きがある • OpenTelemetry Copyright ©2023 NS Solutions Corporation, IBM Corporation. 32
33. ログ 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 33 12 Factor App では、APM（Application Performance Monitoring）などを使うのは あくまで以下のようなことを実施するため、と記載されている • 過去ログの確認 • 傾向分析 • アラート発報 これに対し近年、可観測性への注⽬が⾼まっている。たとえば APM 製品は RCA（Root Cause Analysis）や SLI/SLO 測定、エラーバジェットのバーンレートに基づくオンコールなど 多機能化していることから、ログの優先順位が上がったことに対して違和感はない
34. Chapter 7 Disposability （Order 9 → 7） An application cannot scale, deploy, release, or recover rapidly if it cannot start rapidly and shut down gracefully. We need to build applications that not only are aware of this, but also embrace it to take full advantage of the platform. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 34
35. 廃棄容易性 解説とポイント 「実⾏基盤の利点を最⼤限に引き出すようなアプリケーションを構築する必要がある」 ここで⾔っている実⾏基盤とは、⾔わずもがなクラウド・プラットフォームのこと ⼀般的なクラウドの利点として「スケーリング、デプロイ、リリース、障害復旧などにかかる時間を短縮できること」 が挙げられるが、これを実現するには「素早く起動し、グレースフルにシャットダウンするようなアプリケーション が不可⽋」とある ⼀⼝にクラウドと⾔ってもプラットフォーム毎に特徴が異なるので、何に強みを持っているのかを意識した開発を すると良い ⼀⽅で、ベンダーロックインにも注意が必要 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 35
36. 廃棄容易性 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 36 12 Factor App ではプロセスに着⽬し、レイヤに応じて注意すべきポイントが異なることが説明されていた。（たとえ ば MQ におけるワーカープロセスはグレースフルにシャットダウンする際にジョブをキューに戻すことが肝要。） これに対し、クラウドプロバイダがハードウェアレイヤの廃棄容易性を担保してくれるプラットフォームを提供するようになっ たことで、開発者はアプリケーションレイヤの廃棄容易性により集中できるようになったと⾔える 特に、サーバレス・プラットフォームが流⾏したことで開発者はビジネスロジックに集中できるようになったと⾔われているが、 その中でも、『コンテナのイメージを⼩さく作る』『ステートを持たないように作る』などといった⼯夫は必要
37. Chapter 8 Backing Services （Order 4 → 8） one of the biggest advantages to treating backing services as bound resources is that when you develop an application with this in mind, it becomes possible to attach and detach bound resources at will. A cloud-native application that has embraced the bound-resource aspect of backing services has options. An administrator who notices that the database is in its death throes can bring up a fresh instance of that database and then change the binding of your application to point to this new database. This kind of flexibility, resilience, and loose coupling with backing services is one of the hallmarks of a truly modern, cloud-native application. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 37
38. バックエンドサービス 解説とポイント 「バックエンドサービスをアプリケーションとバインドされたリソースとして 扱うことで、好きなタイミングで、通信するバックエンドサービスを切断 したり接続できるようになる」 「真にモダンでクラウドネイティブなアプリケーションは、バインドを 駆使することで柔軟性、レジリエンシ、疎結合性を兼ね備えてい る」 右の図において、線で表されているのがバインド領域 「クラウドにおいてはストレージやディスクでさえ、バックエンドサービスの ⼀つ」 「フォールバックやフェールセーフを実装するサーキット・ブレーカーも、 バインド領域に存在するため、バインドは重要な考え⽅である」 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 38 （原本より引⽤）
39. バックエンドサービス 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 39 パワーワードが出るくらい熱く語っているように感じたが、検討すべき優先順位としては下がっている。 その背景としては、BaaS（Backend as a Service）として各種サービス毎に専⾨のプロバイダが登 場し、バインドすることが⼤前提になっている、かつ、冗⻑性なども担保されたバックエンドサービスが主 流になっていることが挙げられる。 また、バックエンドサービスの種類としてデータストア、MQ、キャッシュ、認証認可など⾊々あるが、こういった サービス種毎に⾃在に利⽤するバックエンドサービスを切り替えられるような取り組みというのもある。 たとえば Dapr は、MongoDB、PostgreSQL、Redis、AWS DynamoDB、Azure Cosmos DB など様々なデータストアのラッパーとして動作してくれる。
40. Chapter 9 Environment Parity （Order 10 → 9） When discussing the design, build, release, run cycle, I brought up the notion that the “It works on my machine” scenario is a cloud-native anti-pattern. The same is true for other phrases weʼve all heard right before losing hours or days to firefighting and trouble-shooting: “It works in QA” and “It works in prod.” The purpose of applying rigor and discipline to environment parity is to give your team and your entire organization the confidence that the application will work everywhere. [*1] [*1]: “Everywhere” here deserves some air quotes, or at least an asterisk. By everywhere, I actually mean all of the approved target environments, not all possible environments in all possible locations Copyright ©2023 NS Solutions Corporation, IBM Corporation. 40
41. 環境⼀致 解説とポイント 「環境差異があると、『どこかの環境では動いた』ことが『本番環境で動作する保証』にな らない。そして⽕消しやトラブルシュート対応が多くなる原因になる。そのため、『予め対 象として決めた、どんな環境でも動作することが保証できる』ように、環境差異をなくすよう な努⼒をすることが⼤事である」 「環境差異を⽣む主な要素は以下の三つである」 • 時間 • ⼈ • リソース Copyright ©2023 NS Solutions Corporation, IBM Corporation. 41
42. 環境⼀致 解説とポイント - 時間が⽣む環境差異 - 「時間が経つと、開発者がコードの内容を忘れてしまう」 障害が発⽣した場合、開発者はこれを直さないといけない。しかし、機能開 発から時間が経てば経つほど、開発者は実装内容を忘れてしまう（あるい は実装した開発者が離任している可能性もある）ので、バグフィックス等に 必要なコード修正に時間がかかってしまう カナリアリリースやロールバック⾃動化などといった⾼度なリリース⼿法を使うこ とで、実装したソースコードを即座に本番環境にデプロイし分析する、とい うような対策もある Copyright ©2023 NS Solutions Corporation, IBM Corporation. 42
43. 環境⼀致 解説とポイント – ⼈が⽣む環境差異 - 「Heroku のようなブラックボックスの API を呼び出すだけであれば、開発者がデプ ロイも⾏うのは⾄極⾃然な流れだが、インフラをしっかり管理するようなエンタープラ イズシステムだとうまく⾏かない」 「⼈がデプロイをするのであれば、⼈為的なミスによって想定と異なる設定になり得 る」 「そのため、パイプラインによって⾃動化するべき」 インフラを管理するエンタープライズシステムであっても、 同じ組織内からサーバレス・プラットフォームを提供するプロバイダチームを構成し、 開発者チームがインフラを意識せずにデプロイも実施することは可能 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 43
44. 環境⼀致 解説とポイント – リソースが⽣む環境差異 - 「『ローカルだから、似たような役割で簡単に起動できる他のツールで代替しよう』というよう な妥協を繰り返すことで、環境差異が肥⼤化していく」 「Docker といったコンテナツールを使⽤して『本番のような』環境をローカルで利⽤すること も可能」 コンテナと⾔えども、PaaS を完全に再現することは難しい とはいえ、PaaS を需要に応じて払い出すのはなかなかコストもかかる 「環境差異が⽣まれることをリスクとして認識し、抗うことが⼤事である」 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 44
45. 環境⼀致 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 45 クラウドネイティブにおいては、ローカルでの動作確認は信⽤せず、あくまでクラウド 上で動作確認したものだけを信⽤する、という思想が説かれている 特に PaaS は、リソースのプランによって挙動が異なるというような場合もある アーキテクチャ設計する際には、開発環境⽤・ステージング環境・本番環境など で何等かの差異がある場合、よくよく検証するか、コストの問題さえなければ 全く同じリソースを使うべきである
46. Chapter 10 Administrative Processes （Order 12 → 10） The problem with the original twelve- factor recommendation is that it was written in an opinionated way with a bias toward interpreted languages like Ruby that support and encourage an interactive programming shell. Administrative processes were a feature the authors wanted customers to utilize. I contend that, in certain situations, the use of administrative processes is actually a bad idea, and you should always be asking yourself whether an administrative process is what you want, or whether a different design or architecture would suit your needs better. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 46
47. 管理プロセス 解説とポイント 「12 Factor App では Ruby のようなインタプリタ⾔語によって管理プロセスを実⾏することが推奨されているが、偏向的である」 「そもそも、その管理プロセスが本当に必要なものなのか⾃問し、以下のようなものはリファクタリングし、場合によってはアーキテクチャ設計を⾒直す等 すべきである」 • ⼀時的な対応にしかならない、対話型コンソール（REPL）で実⾏するコマンド • スケールしたときにデータの破損や重複あるいは過負荷など、システムに混乱を⽣む原因となる、特定の時刻に実⾏されるスクリプト • （実⾏されたかどうか把握されない、あるいは複数回実⾏するとデータの破損や重複の原因となる、）⼀度のみ実⾏されるスクリプト • 例）DB マイグレーション 対話型コンソールで実⾏する管理プロセスは、破棄と⽣成を繰り返されるコンテナ上で実⾏しても「⼀時的な対応にしかならない」 原⽂では「DB マイグレーション」が並列に記述されていたが、実体としては DB スキーマを更新する等の「⼀度のみ実⾏されるスクリプト」であると解釈 たとえば Prisma や TypeORM といった ORM はマイグレーションの履歴を DB のテーブルとして持ち、⼀度のみ実⾏されることが保障されているため、 そういった仕組みを導⼊すると良い Copyright ©2023 NS Solutions Corporation, IBM Corporation. 47
48. 管理プロセス 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 48 特定の時刻に実⾏されるスクリプトのリファクタリング案として、原⽂では「処理を API 化してアド ホックに随時呼び出す」や「別のサービスとして切り出す」といった⽅法が挙げられているが、システ ムの複雑性が増すことで運⽤の難易度が上がってしまう アーキテクチャ設計のタイミングで、どんな管理プロセスが発⽣しうるかをできるだけ網羅的に検 討し、その管理プロセスを無くす⽅向でアーキテクチャを⾒直していくことが肝要である • サービス間のデータ整合性 • DB のインデックス • …etc
49. Chapter 11 Port Binding （Order 7 → 11） Embracing platform-as-a-service here allows developers and devops alike to not have to perform this kind of micromanagement any- more. Your cloud provider should be managing the port assignment for you because it is likely also managing routing, scaling, high avail- ability, and fault tolerance, all of which require the cloud provider to manage certain aspects of the network, including routing host names to ports and mapping external port numbers to container- internal ports. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 49
50. ポートバインディング 解説とポイント ポートの割当をマイクロマネジメントをするのは避けよう。 クラウド環境を有効活⽤し、環境によって異なるポートバインディングでも開発者は コードを変更しなくても外部から設定できるようにする。 クラウドプロバイダーの提供する機能を使ってアプリを公開しよう Copyright ©2023 NS Solutions Corporation, IBM Corporation. 50
51. ポートバインディング 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 51 ポートバインディングに記載されている内容は単体で意味があるわけではなく、1. API First や 8.バックエンドサービスと⼀緒に対応することにより、疎結合なアプリケーションを作ることを⽬ 指している。 もともと12 Factor Appにもポートバインディングという章はあったが、 Beyond the Twelve-Factor Appではエンタープライズシステムを考慮して制約が緩くなっている。 Javaの場合はTomcatやWASではなく Jetty を使え︕と⾔っているが、⾊々な制約があるのだから 無茶な話だよ。そこまでしなくても良いから、アプリケーションとアプリケーション・サーバーを 1:1の関係に保とう。と⾔っていると理解した。
52. Chapter 12 Stateless processes （Order 6 → 12） Applications should execute as a single, stateless process. As mentioned earlier in the book, I have a strong opinion about the use of administrative and secondary processes, and modern cloud-native applications should each consist of a single,1 stateless process. This slightly contradicts the original 12 factor discussion of stateless processes, which is more relaxed in its requirement, allowing for applications to consist of multiple processes. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 52
53. ステートレスプロセス 解説とポイント 「アプリケーションは単⼀の、ステートレスなプロセスとして実⾏されるべき」 「アプリケーションのメモリ内にセッション情報を保持させてはいけない。セッションは有 効期限付きのデータストアに保存し、バッキングサービスを使⽤して取得する。」 ステートレスの定義が曖昧な⽅は、プロセス内に状態を維持してはならないと考え てください。ステートを作ってはいけないのではなく、管理はプロセスの外で⾏うという ことです。 原⽂では、「⻑期間持続するすべての状態はアプリケーションの外部にあるバッキン グサービスによって提供されるべき。」と記載されています。これは、クラウドネイティブ アプリの特徴である廃棄⽤意性、拡張性を実現するために必須の要件です。 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 53
54. Chapter 13 Concurrency （Order 8 → 13） Adding CPUs, RAM, and other resources (virtual or physical) to a single monolithic application is called vertical scaling, and this type of behavior is typically frowned upon in civilized society these days. A much more modern approach, one ideal for the kind of elastic scalability that the cloud supports, is to scale out, or horizontally. Rather than making a single big process even larger, you create multiple processes, and then distribute the load of your application among those processes. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 54
55. 並⾏性 解説とポイント 「もしあなたが使い捨てのステートレスでシェア・ナッシングのプロセスを構築しているのであれば、⽔平スケーリングをフルに活 ⽤し、アプリケーションの複数の同時インスタンスを実⾏することで、クラウドで真に繁栄することができるでしょう。」 クラウド環境を有効活⽤するためには垂直スケールより⽔平スケールを使うべし。 • 垂直スケール CPU、RAM、その他のリソース（仮想または物理）を単⼀のモノリシック・アプリケーションに追加すること。アプリケーショ ンが処理能⼒の限界に達した場合の解決策として採⽤されてきた。 • ⽔平スケール 単⼀の⼤きなプロセスをさらに⼤きくするのではなく、複数のプロセスを作成し、アプリケーションの負荷をそれらのプロセスに 分散させる ほとんどのクラウド・プロバイダーは⽔平スケールに対応しており、負荷やシステムで利⽤可能な状況に応じて、 アプリケーションのインスタンス数を動的にスケールさせるルールを設定できる。 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 55
56. 並⾏性 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 56 ⽔平スケーリングを実現できるのは、7. 廃棄容易性 や 12.ステートレスプロセス など他の要素を達成済みだからこそ。 マイクロサービスアーキテクチャを実現できている場合は必要なサービスだけ を⽔平スケーリングしやすいが、モノリシックの場合⽔平スケーリングではなく 単純なリソース追加の⽅が効率が良いこともある。
57. Chapter 14 Telemetry （New） If your creation is thousands of miles away, and you can’t physically touch it or bang it with a hammer to coerce it into behaving, what kind of telemetry would you want? What kind of data and remote controls would you need in order to feel comfortable letting your creation float freely in space? When it comes to monitoring your application, there are generally a few different categories of data: •Application performance monitoring (APM) •Domain-specific telemetry •Health and system logs Copyright ©2023 NS Solutions Corporation, IBM Corporation. 57
58. テレメトリー 解説とポイント 「12 Factor App にはテレメトリーという概念は含まれていない。テレメトリーの辞書的定義では、特別な機 器を使⽤して何かを測定し、その測定値を無線を使って別の場所に送信することを意味する。」 「テレメトリーの使⽤は、クラウド・ネイティブ・アプリケーションの不可⽋な部分であるべきだ。」 テレメトリーとして取得すべきと記事内で記載されているカテゴリーは以下3つ - アプリケーション・パフォーマンス・モニタリング（APM） - ドメイン固有の遠隔測定 - ヘルスログとシステムログ Copyright ©2023 NS Solutions Corporation, IBM Corporation. 58
59. テレメトリー 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 59 クラウドネイティブ、ハイブリッドクラウド、マルチクラウドと複雑な環境を管理する時代なので、 オブザーバビリティが重要である。本記事では3カテゴリーしか触れられていないが、他にも取 得すべき内容も検討する必要がある。 • ビジネスレベルでの情報 新規ユーザー登録数、解約数、A/Bテストの結果 • エンドユーザーモニタリング モバイルアプリのクラッシュ、ブラウザのjsエラー、レイテンシー • デプロイパイプラインレベル アプリのデプロイ反映時間、デプロイ頻度、ビルドパイプラインの状況
60. Chapter 15 Authentication and authorization （NEW） A cloud-native application is a secure application. Your code, whether compiled or raw, is transported across many data centers, executed within multiple containers, and accessed by countless clients—some legitimate, most nefarious. Even if the only reason you implement security in your application is so you have an audit trail of which user made which data change, that alone is benefit enough to justify the relatively small amount of time and effort it takes to secure your application’s endpoints. Copyright ©2023 NS Solutions Corporation, IBM Corporation. 60
61. 認証と認可 解説とポイント 「12 Factor App では 認証・認可について⾔及されていなかった。」 「セキュリティはエンタープライズ向けであろうと、モバイルデバイス向けであろうと、クラウド向けであろう と、最も重要な側⾯の⼀つだ」 理想的には、すべてのクラウドネイティブアプリケーションはエンドポイントをすべてRBAC（ロールベー スのアクセス制御）で保護するべき。アプリケーションへのすべての要求は、誰がその要求を⾏ってい て、その利⽤者がどのロールに属しているかを知るべき。これらのロールは、呼び出し元のクライアント がアプリケーションが要求を受け⼊れるための⼗分な権限を持っているかどうかを決定する。 どんなアプリケーションであっても、開発の初⽇からセキュリティの設計/実装に取り組むべき Copyright ©2023 NS Solutions Corporation, IBM Corporation. 61
62. 認証と認可 考察 Copyright ©2023 NS Solutions Corporation, IBM Corporation. 62 クラウド活⽤を推進するためにリフト・シフトという単語が使われてきた。 • オンプレ環境をクラウドに移⾏しよう（リフト） • 単純な移⾏ではなく、クラウドに最適化したアプリに回収しよう（シフト） 本章では認証と認可の具体的な⽅針について細かい記載があるわけでは なく、セキュリティのシフトレフトの重要性を訴えていると理解した。 「どんなアプリケーションであっても、開発の初⽇からセキュリティの設計/実装 に取り組むべき」
63. 本⽇のアジェンダ 1. オープニング 2. Beyond the Twelve-Factor App のご紹介 3. QA・クロージング Copyright ©2023 NS Solutions Corporation, IBM Corporation. 63
64. 本⽇のまとめ “12 Factor App” は、Heroku が SaaS アプリケーション開発現場の経験・観察から理想的な プラクティスをまとめた、12 項⽬の⽅法論である “Beyond the Twelve-Factor App” は、Pivotal（現 VMware） が ”12 Factor App” をクラウドネイティブに対応できるように発展させた、15 項⽬の⽅法論である 本⽇はこの 15 項⽬について解説しました Call to Action! 「15 項⽬全てが実践されていることが理想ではあるが、現実には妥協が付き物。」 「妥協する際には、理由込みで必ず意思決定しましょう。」 今の皆さんの開発現場で総点検してみてはいかがでしょうか Copyright ©2023 NS Solutions Corporation, IBM Corporation. 64
65. We are hiring!! Copyright ©2023 NS Solutions Corporation, IBM Corporation. 65 ⽇鉄ソリューションズでは、 クラウドネイティブ技術を⽤いて お客様の DX を推進する仲間を募集中です。 ご興味ある⽅は、 ぜひお問い合わせください。 弊社⼈事より、ご連絡を差し上げます。 🔍「NSSOL キャリア採⽤」 採⽤ページ︓ https://www.nssol.nipponsteel.com/re cruit/careers/
66. リファレンス 12 Factor App : https://12factor.net/ja/ Beyond the Twelve-Factor App : https://tanzu.vmware.com/content/ebooks/beyond- the-12-factor-app Copyright ©2023 NS Solutions Corporation, IBM Corporation. 66
67. 事後アンケートのお願い Copyright ©2023 NS Solutions Corporation, IBM Corporation. 67 https://app.sli.do/event/fp3Xrr7n3Dw9C2hJurVWmU より良いイベントを企画するため、 ぜひアンケートへのご回答をお願いいたします。 こんなテーマの話を聞きたい︕︕ 説明だけではなくハンズオンがやりたい︕ 社内勉強会で登壇してほしい︕ などなど、コメントいただけると嬉しいです。