サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
speakerdeck.com/ytaka23
Developers Summit 2023 Summer で使用したスライドです。 サーバーレスアーキテクチャは強力ですが、同時に冪等性やトランザクションなど特有の考慮事項が必要であり、高い設計力が求められます。ところで、安全なプログラムを書く上で、静的型付き言語は広く利用されていますね。型はいわば実行前に間違いを検出できる仕組みであり、その背後には「プログラムの正しさ」を厳密な数式で記述し分析する理論が存在します。では、同様に「サーバーレスの正しさ」も厳密な数式で記述することは可能でしょうか?本講演ではAWS Lambdaを用いた設計を例として取り上げながら解説します。 イベント概要:https://event.shoeisha.jp/devsumi/20230727/session/4486/ ブログ記事:https://ccvanishing.hateblo.jp/entry/20
ハードル激低LT大会ッ! #02 で使用したスライドです。 Amazon S3 の強い Read-after-write 一貫性と、その同期プロトコルの検証に使用された形式手法の一種、P 言語のさわりを紹介しています。 イベント概要:https://smarthr.connpass.com/event/278899/
AWS Dev Day 2022 Japan で使用したスライドです。 AWS Lambda を初めとするサーバーレスコンピューティング基盤には、 * 複数の関数が同時に実行され共有リソースにアクセスしうる、本質的に並行システムである * Warm Start により関数インスタンスが内部状態を残したまま再利用されうる * 一つのリクエストに対して複数回の実行が行われうる、いわゆる At-Least-One 特性 といった特性があり、通常のプログラムと比較して実行モデルが複雑かつアンコントローラブルな要素を多く含みます。関数を実装する側はこのような「プラットフォームの都合」を考慮して冪等性など細かい挙動に気を配りつつプログラムを書くことになり、これは一般にかなりの実装コストになります。また、アンコントローラブルな要素は、関数の実装から実際の挙動を静的に検査することを難しくしています。 この
AWS Dev Day Online Japan 2021 で使用したスライドです。 許可しているはずのインスタンス間でなぜか通信が通らない、逆に意図しないアクセスが許可されていた、そしてこの種のデバッグはかなり辛い…! そんなときは、通信経路を自動でチェックしてくれる VPC Reachability Analyzer の出番です。この機能が面白いのは、チェックの際に実際に通信を行う必要がなく、いわば設定項目の「意味」を理解した上で結果を「推論」してくれる点。本講演では、背景となる数学的な理論や論文にも踏み込みつつ、AWS ネットワークの意味論を用いた検査技術を解説します。 イベント概要:https://aws.amazon.com/jp/about-aws/events/2021/devday/ ブログ記事:https://ccvanishing.hateblo.jp/entry/20
CI/CD Conference 2021 で使用したスライドです。 S3 オブジェクトを不必要に公開してしまったり、あるいは遮断されるべきネットワークが繋がってしまったりといったセキュリティ上の設定ミスは、可能な限り避けたいものです。 このようなインフラ層に対するテストを従来の CI/CD の一部として組み込む場合、「個別の設定項目が条件を満たすことを確認する」または「実際にデプロイした環境に対してアクセスしてみる」といった形でテストを行うことが一般的でしょう。 しかしセキュリティ設定には、「複数の設定項目が絡み合った結果、最終的なアクセス可否が定まる」かつ「実際にデプロイする前に影響範囲を知りたい」といった要求があり、上にあげたテストの形式とはあまり相性が良くないのが事実です。 この問題に対して有効な手法の一つが Automated Reasoning です。Automated Rea
July Tech Festa 2021 で使用したスライドです。 S3 オブジェクトを不必要に公開してしまったり、遮断されるべきネットワークが繋がってしまったりといった、セキュリティの設定ミスは是非とも避けたいものです。では、多数の設定項目が複雑に相互作用する状況で、最終的な設定の「正しさ」はどうしたら保証できるでしょうか? この問題に対して有効な手法の一つが Automated Reasoning です。Automated Reasoning を活用することで、AWS 上の設定項目を数学的に解析し、実際のアクセスを行うことなくアクセスが可能かどうかを「推論」することが可能になります。本セッションでは、この Automated Reazoning をエンドユーザの立場から活用する方法に加え、背景にある数学的な理論も含めて、セキュリティの「正しさ」を保証する仕組みの内幕を解説します。 イベ
Kubernetes Meetup Tokyo #42 で利用したスライドです。 Kubernetes における Policy as Code の実装として最も広く使われているツールは Open Policy Agent (OPA) とその Kubernetes アダプタである Gatekeeper です。OPA は CNCF Graduated に位置付けられおり、デファクトスタンダードであると言えます。しかし OPA は記述言語として Rego を採用しており、学習コストの高さは否めません。 一方、OPA 以外のポリシエンジンとしては、Kyverno が CNCF Sandbox に登録されています。OPA と異なり Kyverno ではポリシの記述に YAML を用いるため学習コストは低いですが、その分、表現力に劣ります。 これらのツールに対して今回紹介する Kubewarden で
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか? 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
July Tech Festa 2021 winter で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか? この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要:https://techfesta.connpass.com/event/193966/ ブログ記事:https://ccvanishing.hateblo.jp/entry/2021/01/24/185819 録画:https:/
Infra Study Meetup #9 で使用する予定だったスライドです。
Kubernetes Meetup Tokyo #35 で使用したスライドです。 Kubernetes において Pod を配置する Node を決定する手続きをスケジューリングと呼びます。多くのユースケースではデフォルトのスケジューリングで充分ですが、機械学習基盤や大規模なネットワークストレージとの併用など、一部の用途ではドメイン知識を反映したスケジューリングが必要になります。 このような場合、従来は JSON Webhook で動作する Scheduler Extender が使用されていましたが、拡張性の乏しさや実行時オーバヘッドに課題がありました。今回紹介する Scheduler Framework は、この問題を解決するために SIG Scheduling により実装が進められてきたプロジェクトです。 前回、2019 年の 2 月の段階 (https://speakerdeck.
Infra Study Meetup #7 で使用したスライドです。 Kubernetes はその高い拡張性を背景として、コンテナオーケストレータのデファクトスタンダートの地位を獲得しました。しかし、Kubernetes の Node をそのままエッジデバイスの管理に延伸しようとすると、ネットワークの不安定性が課題になります。 このようなエッジに特有の課題を解決するため、CNCF の IoT Edge Working Group 主導で開発が進められている OSS として KubeEdge があります。本発表では、KubeEdge のアーキテクチャ上の特徴や従来の Kubernetes とのコントロールフローの違いについて解説します。 イベント概要:https://forkwell.connpass.com/event/190074/ 録画:https://www.youtube.com/
CloudNative Days Tokyo 2020 で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか? この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要:https://event.cloudnativedays.jp/cndt2020 ブログ記事:https://ccvanishing.hateblo.jp/entry/2020/09/10/044848
Infra Study Meetup #5 で使用したスライドです。 複数のチームでひとつの Kubernetes クラスタを共有したい場合、Namespace に紐づいた Role や Policy を使用することでチームごとに環境の管理が容易になります。しかし通常の Namespace はフラットな構造しか表現できないため、ある程度複雑な組織では Namespace を用いた各チームへの管理の移譲がうまくいかないケースがあります。 この問題を解決するために、階層構造を持つ Namespace を仮想的に扱うためのツール Hierarchical Namespace Controller (HNC) の開発が進められています。本セッションでは、デモを交えて HNC の仕組みについて紹介しました。 イベント概要:https://forkwell.connpass.com/event/183
Cloud Operator Days Tokyo 2020 で使用したスライドです。 インフラをコードとして管理することで環境構築の再現性を担保する IaC の手法は、ここ数年で急激に普及しました。しかし、そのコードに対するテストは簡単なチェックに留まっていることも多く、実際に環境を構築してみたら上手く動かない、という状況がしばしば起こります。そこで本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 実際にインフラをコードで管理していて、早い段階で設定ミスを検出して無駄なコストを削減したい方におすすめのセッションです。 イベント概要:https://cloudopsdays.com/ ブログ記事:https://ccvanishing.hateblo.jp/entry/2020/07/30/173935
JAWS コンテナ支部 #16 で使用したスライドです。 Kubernetes 上にデプロイされたアプリケーションが安定して稼働するためには、複数の Pod が複数の故障ドメインにまたがって配置されていることが重要です。反面、一般には故障ドメインをまたぐ通信はオーバヘッドがかかるため、パフォーマンスの観点から言うと通信はできるだけ同じ故障ドメイン内で完結している方が有利になります。 今回の LT では、この「故障ドメイン内で通信を完結させる」機能である Service Topology を紹介します。Node に対して Label を用いてグルーピングを行うことで、Service リソースによるロードバランスが、同一の故障ドメイン内に優先して行われるようになる機能です。 イベント概要:https://jawsug-container.connpass.com/event/160835/
KubeFest Tokyo 2020 で使用したスライドです。 Kubernetes を運用する上で、大量の Manifest の複雑性をどう扱うかは避けられない課題です。テスト用と本番用のクラスタで設定が微妙に違っていたり、あるいは複数のチームが管理する Manifest に共通して必要な設定がある、といった現実的な状況下では、何らかの形で Manifest の共通化や環境差分の管理が必須です。実際、この問題を解決するために様々なツールが考案され、また広く使用されています。Helm や Kustomize はその代表格です。 一方、今回紹介する Kpt は、Helm や Kustomize とは一線を画したアプローチを採用しています。Kpt の大きな特徴は、入力と出力の間に「テンプレートとその代入結果」のような非対称性を導入せず、同じ形式の YAML を用いる点にあります。Kpt の各
Infra Study Meetup #2 で使用したスライドです。 Kubernetes では通常、Pod が配置される Node は Scheduler によって自動的に選択されるため、ユーザが意識する必要がありません。しかし、ひとつのクラスタに様々な性質を持つ Pod を同時にデプロイすることを考えると、Pod の配置を Node や他の Pod との関連でもっと精密に指定したいユースケースが増えてきます。 このような需要に応えるため、Scheduler には Node を選択するためのアルゴリズムをカスタマイズ可能にする仕組みが備わっています。本スライドで紹介する Scheduling Profile はそれをさらに効果的に運用するための仕組みです。従来はアルゴリズムごとに Scheduler が必要でしたが、現在ではアルゴリズムを Profile としてまとめ、さらにひとつの S
Kubernetes Meetup Tokyo #29 で使用したスライドです。 扱う環境やアプリケーションごとに Kubernetes Manifest の内容を変えたいとき、代表的な方法が二種類あります。 ひとつは Helm のように「穴」が空いたテンプレートを用意しておき、必要に応じて値を当てはめて最終的な YAML を生成する方法。この方法はわかりやすいですが、カスタマイズできるポイントが最初から決まっており、さらに共通した構造を持つテンプレートを階層化することもできないため、全体として自由度が乏しくなるという欠点があります。 もう一つは Kustomize のようにベースとなる YAML を用意して、必要に応じて部分的に上書きしていく方法。こちらの方法ではカスタマイズできるポイントは限定されず、さらに作成した YAML をベースにして追加カスタマイズを加えることも可能ですが、出力
Developers Summit 2020 で使用したスライドです。 言葉というものは曖昧です。複数人が「ともにつくる」システムにおいて、メンバ間で仕様を正しく共有することは非常に重要ですが、一方で言葉の裏側に隠された「暗黙の仮定」を見抜くことは簡単ではありません。このような仕様の曖昧性への対抗手段として、本セッションでは「形式手法」を紹介します。形式手法ではシステムの挙動を数学的に記述することにより、自然言語の持つ曖昧性を排除し、仕様が満たされるかどうかを厳密に検証することが可能になります。あなたの頭の中にある仕様がどのように「数学的な記述」に変換されるのか、具体例を通して体験してみませんか? イベント概要:https://event.shoeisha.jp/devsumi/20200213/session/2380/
OpenShift.Run 2019 で使用したスライドです。 Kubernetes において Deployment の作成から Pod の起動に至る流れは隠蔽されており、通常エンドユーザは Pod がどの Node に配置されるのかを気にする必要はありません。しかし、運用がある程度の規模になると、CPU やメモリなどクラスタが持っているリソースを効果的に使い切り、さらに障害時にサービスが停止しないようにするためには、Pod の配置にまで気を配る必要があります。 Pod をどの Node に配置するかの判断をスケジューリングと呼びます。本講演では Kubernetes のスケジューリングの仕組みと、それを運用する上で現実的に生じる課題、さらにその対策までをまとめて包括的に解説しました。 イベント概要:https://openshift.connpass.com/event/151473/
Kubernetes Invitational Meetup Tokyo #4 で使用したスライドです。 複数の Pod が通信し合って実行を進めるような Job をデプロイする場合、一部の Pod だけが先に配置された状態で Node のリソースを使い切ってしまうと、後続の Pod が配置できずにデッドロックに陥ることがあります。 これを防ぐため、特定のグループに属する Pod を一度に全て配置するか、あるいは全て Pending のまま留めるかという All of Nothing の配置戦略を Gand Scheduling あるいは CoScheduling と呼びます。 今回紹介した kube-batch は Gang Scheduling を実現する特殊スケジューラの一種です。Gang Scheduling 以外にも、複数のキューを定義してクラスタのリソースをキュー間で均等に配分
July Tech Festa 2019 で使用したスライドです。 近年、テストを書く文化は広く普及しており、開発フローにおいて自動テストを組み込むことはもはや常識となりました。しかしよく考えてみると、有限個のテストケースが保証しているのは、所詮「特定の有限個の入力に対する出力」にしか過ぎません。では「あり得る全ての入力」に対してプログラムの性質を保証することは果たして可能でしょうか? この問いに対する答えのひとつが「定理証明」と呼ばれる手法です。定理証明では、数学的な「証明」をプログラム上でエンコードすることにより、真に「全ての入力」を扱うことができます。本セッションではこの定理証明を取り上げ、従来のテストとの考え方の違いや具体的な適用方法について、サンプルを交えつつ解説します。 イベント概要:https://2019.techfesta.jp/speakers#A10
Cloud Native Developer JP 第 13 回 で使用したスライドです。 Kubernetes は学習コストが高いとよく言われます。その理由の一つとして、新しい機能や関連ツールが次々と登場するスピードと比較して、環境構築が大掛かりになりやすく、気になった機能をすぐに試すことが難しいという事情考えられます。 そこで今回は、Docker コンテナを利用してローカルにクラスタ構築するツール Kind(Kubernetes IN Docker)を紹介し、実際に Kubernetes v1.16 の新機能である Pod Topology Spread Constraints のデモを披露しました。 イベント概要:https://cnd.connpass.com/event/154414/
Kubernetes Meetup Tokyo #25 で使用したスライドです。 Kubernetes において、Pod を分散させる基本単位は Node です。しかし現実には複数の Node に Pod が分散している状況であっても、それらの Node が同じ Availability Zone やラックにホスティングされていた場合には、障害が原因で Pod が全滅しサービス停止に陥る可能性があります。 この問題を解決するため、Kubernetes v1.16 ではアルファ機能として Topology Spread が導入されました。この機能を有効にすると、Node に Label を付与することで故障ドメインを表現した論理的なグループを作成し、そのグループ単位での Pod の分散方法を指定することができます。 イベント概要:https://k8sjp.connpass.com/even
CI/CD Test Night #5 で使用したスライドです。 コンテナを利用してローカルにマルチノード Kubernetes クラスタを立ち上げるツール Kind(Kubernetes IN Docker)を紹介します。 従来、CI 用に Kubernetes クラスタが必要な場合、取れる選択肢は「Pull Request ごとに Namespace を作成」もしくは「Pull Request ごとにマネージドクラスタを振り出し」のいずれかでした。Kind を CI パイプラインに組み込むことにより、従来よりも素早く、かつ低コストでクラスタを立ち上げて使い捨てることが可能になります。 イベント概要:https://testnight.connpass.com/event/145238/
builderscon tokyo 2019 で使用したスライドです。 本セッションでは、形式手法 (formal methods) を用いた分散アルゴリズムの検証について解説しました。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。 なお解説として取り上げたのは、AWS による事例論文でも有名なモデル検査器 TLA+ です。講演前半で形式手法の一般論に触れたのち、後半では分散トランザクションを実現するための TCC (Try-Confirm/Cancel) Pattern のモデリングと検証を行いました。 講演概要:https://builderscon.io/tokyo/2019/session/fa356ee3-6be9-4850-ac9e-037bd34aabaa 録画:https://www.y
CircleCI ユーザコミュニティミートアップで使用したスライドです。 Kind(Kubernetes IN Docker)は、Kubernetes の Node をコンテナ化することで、マルチノードクラスタをローカルで簡単に立ち上げられるようにするツールです。Kind を使用することで、コンテナが動く環境ならどこでも使い捨ての Kuberentes クラスタを作成することができるため、クラスタの動作に依存するようなツールの検証を非常に手軽に行うことができます。発表中ではこの Kind を CircleCI 上で起動させて E2E テストを行う方法を解説しました。 イベント概要:https://circleci.connpass.com/event/140666/
CloudNative Days Tokyo 2019 で使用したスライドです。 Kubernetes は既にコンテナオーケストレータのデファクトを獲得し、多種多様なアプリケーションがデプロイされるプラットフォームとなりました。この流れの中で、従来の機能ではカバーできない複雑なコンテナ配置ロジックや、リソース集積率の最適化に対する需要も高まっています。本講演では、カスタマイズの手法から次世代の特殊スケジューラまで、Kubernetes におけるコンテナ配置のすべてをお話しします。 イベント概要:https://cloudnativedays.jp/cndt2019/ ブログ記事:https://ccvanishing.hateblo.jp/entry/2019/07/30/112634 録画:https://www.youtube.com/watch?v=EsZLJT5uQ5E
次のページ
このページを最初にブックマークしてみませんか?
『y_taka_23 (@ytaka23) on Speaker Deck』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く