Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes to Achieve Both Frequent Updates and Stability
Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes to Achieve Both Frequent Updates and Stability
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。 「逆コンウェイの法則」が持ち出された議論が苦手なんどけど、なんでなのかな。コンウェイの法則はよく理解できるんだがー。 — Kazunori Otani (@katzchang) February 28, 2023 この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。 コミュニケーションがかえって増える問題コンウェイの
Google、モノリスとマイクロサービスのいいとこ取りをする「Service Weaver」フレームワークをオープンソースで公開 Googleは分散アプリケーションの開発とデプロイを容易にするフレームワーク「Service Weaver」をオープンソースで公開しました。 Introducing Service Weaver! Service Weaver is an open source framework for building and deploying distributed applications. It allows you to write your application as a modular monolith and deploy as a set of microservices. Learn more → https://t.co/XmnVALYXNC pic
大きく変化した「人とシステム」の関係 企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。 マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。 「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWe
はじめに こんにちは。 2022年の4月から、さくらインターネット株式会社に新卒入社し、7月よりSRE室という部署に配属されました、菅原大和(@drumato)と申します。 本記事では、7月の配属から今日(記事執筆時点では2022/10/31)にかけての3ヶ月間、社内のKubernetesクラスタ運用状況を調査し、現状の課題を明確にした上で、社内のKubernetesクラスタ運用状況を改善する基盤の設計と開発に取り組んできましたので、その内容をご紹介します。 その過程で得られた知見や、今後必要になってくるであろう、不足している機能についても合わせて共有します。 また、本プロジェクトの背景として、SRE室という部門の目的や今後実現したい世界観についてもお話しできればと思います。 本記事の全体を通して、技術的な側面よりもプロジェクトの背景や目的を重点的にお伝えします。 本プロジェクトの概要 本
はじめに コンテナイメージのセキュリティ診断ツール｢Dockle｣を正式にリリースしました。コンテナイメージから特に危険な項目をチェックするとともに、イメージに保存されているコマンド履歴をもとにベストプラクティスに沿ったコンテナイメージが作れているかも確認できます。 https://github.com/goodwithtech/dockle 導入まで インストールしたら、あとはイメージ名を指定すればOKです。 他には何も用意する必要がありません。そう、Dockerすら不要です。 各OSでのインストール手順はこちら。 プライベートレジストリにも対応してます。プライベートレジストリのイメージを利用する方法はこちら。 Dockleの公式イメージも用意してます。利用方法はこちらをご確認ください。 実行結果は、以下のようにでます。 問題なければ ｢PASS｣が表示されます。 特徴 Dockleの特
はじめに エッジコンピューティングの一丁目一番地と言えば、ラズパイやNVIDIA Jetsonみたいな エッジデバイスでKubernetesですよね(!?)。k3s、k0s、MicroK8sと軽量Kubernetesは、前々からKubernetes on エッジデバイスの代名詞ですし、KubeEdgeやEclipse FoundationのEdgeNative WGが推進するioFogなど、エッジコンピューティング向けのKubernetes関連のオープンソースプロジェクトも増えつつあります。そして、KubeCon + CloudNativeConでもKubernetes on Edge Dayなイベントをやったりと、コミュニティの盛り上がりも高まっています。 そんな中、エンタープライズ向けのKubernetesディストリビューションを提供しているレッドハットが、軽量版OpenShiftとし
はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境
こんにちわ、サイト管理者のわかっち (@wakatchi_tech) です。 質問者 マイクロサービスでシステム作ったらトランザクション管理がしんどいです。 こんな質問をいただきました。 マイクロサービスアーキテクチャでシステムを構築した際、更新対象が複数のサービスをまたがる場合は、トランザクションの扱いが途端に難しくなります。なかでも、障害発生時に各サービス間の処理をロールバックするためには補償(補正)トランザクションが必要になり、複雑なトランザクション制御が求められます。 補償トランザクションとは、処理の途中で失敗した場合に、それを取り消すことで実行結果を打ち消す処理のことです。補償トランザクションの実装は、打ち消す処理を提供するサービスと、それを呼び出すサービスの双方に負担があり、設計や実装が複雑になりがちです。 トランザクションには、1つのトランザクション内で1つのリソース（DBな
Microservicesアーキテクチャの トランザクション管理の現実 Shingo Yamanari Principal Cloud Solution Engineer Oracle Corporation Japan, Solution Architect May 17th, 2022 Copyright © 2022, Oracle and/or its affiliates. All rights reserved. | 2 1. マイクロサービスの世界観 2. マイクロサービス間の一貫性の仕組み 3. 既存システムのマイクロサービス化の現実 4. オラクルのトランザクション管理ソリューション Agenda マイクロサービスの世界観 デジタルトランスフォーメーション | 社内業務の効率化から新ビジネスの創造へ ビジネスにもとめられる進化のスピードと品質 サービスの早期リリース
はじめに 本稿は「.NET 6移行祭り！ C# Tokyo」イベントで発表した「金融の基幹システムを1年半かけて .NET 6に移行した話」の内容を文書化したものです。 [2022.08.28追記] さて、はじめにおことわりを。 おもったより大きな反響があって、想定より多く読まれており、とくに正しく伝えられていない箇所があると思い、少し補足を入れました。 ここで基幹システムといっていますが、金融の勘定系システムという意味ではありません。 基幹システムというとCore Systemという意味（これは勘定システムでしょうね）と、Mission Critical Systemの2つがあると思います。 本稿の対象は後者で、システムのお客様が、Mission Critical Systemと判断されて基幹システムとして扱われています。 金融の勘定系とは規模や複雑性、クリティカルな度合も異なりますが、
オラクルは近々、マイクロサービスアプリケーション向けに「Oracle Transaction Manager for Microservices（以下、TMM）」をリリースする。まず導入としてマイクロサービスに関する課題を説明し、次にTMMの概要やサポート範囲、最後にオラクルの今後の展望を明かす。 マイクロサービスにおける課題、オラクルの解決策 まずはマイクロサービスの対極にある従前のモノリシック（アプリケーション）から確認しよう。これは1つの巨大岩のようなものだ。内部でローカルトランザクションを実行するため、データベースが絶えず更新され、モジュール間には多数の依存関係があり、コードもテーブルも膨大な数を抱えている。巨大な固まりなので、保守の困難さなどさまざまな課題を抱えている。 一方、マイクロサービスはより小さな独立したモジュールで構成されるもので、各モジュールは個別に開発・テスト・デプ
マイクロサービスの活用はネット企業が中心だったが、今や一般企業にも広まりつつある。その原動力は、システムを俊敏に変更したい、保守性を高めたいというニーズの高まりだ。ふくおかフィナンシャルグループ傘下の「みんなの銀行」の事例でメリットを見よう。 「競合のフィンテック企業はクラウドに素早くシステムを構築し、プロダクトを磨き上げる。同じ土俵のクラウドに乗り、アジャイル（俊敏）に改善していく」。スマートフォン専業銀行、みんなの銀行の宮本昌明執行役員CIO（最高情報責任者）はGoogle Cloud上に一から構築した勘定系を含む銀行システムのコンセプトをこう話す。 システムの俊敏な変更を可能にするために選んだのが「マイクロサービスアーキテクチャー」だ。比較的小さなサービスをAPI（アプリケーション・プログラミング・インターフェース）経由などで疎結合に連携させて、一連の処理を実現する。従来に比べてサー
この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です！よろしくお願いいたします！ 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります！ techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1，デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2，batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3，泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「
▼イベント▼ Spring Fest 2021 https://springfest2021.springframework.jp/ ▼配信アーカイブ▼ https://www.youtube.com/watch?v=9-yDaFlGTxE
米Tesla（テスラ）が全く信じられない発表をした。驚愕（きょうがく）したという意味であって、信頼できないという意味ではない。 テスラのIR資料＊1を確認していると、2021年第2四半期の「株主デッキ（Shareholder Deck）」＊2に目が留まる。現在、自動車各社ともに半導体不足で呻吟（しんぎん）しているが、テスラは「我々の開発チームは、半導体不足から引き起こされる製造の問題について対応するために、これまでにない取り組みを開始している。我々のエレキとファームウエアのチームは、19もの新たなコントローラーを用意し半導体不足に対応するために鋭意、設計や検証に取り組んでいる」というのだ＊3。 ＊1 TESLAのIR資料 ＊2 2021年第2四半期のShareholder Deck ＊3 原文はOur team has demonstrated an unparalleled abilit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
