並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 93件

新着順 人気順

gkeの検索結果1 - 40 件 / 93件

  • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

    公開日 2024/05/28更新日 2024/12/02注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット会員限定コンテンツ無料登録してアーキテクチャ

      注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
    • 個人開発者がGoogle Cloudの環境構築でお財布を守るために最初にすべきこと - Qiita

      Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに 自分は2年くらい業務でGCP(今はGoogle Cloudですね)を使っていたのですが、友達が個人開発でGoogle Cloud使いたいから手伝ってとのことで、久々にコンソール触りたいなーと思ったので環境構築を手伝うことにしました。友達のクレジットカードが紐づいた環境なので自分の環境以上に課金やセキュリティに対して注意しなくてはなりません。課金だけでなく友情も爆発してしまいかねませんので 今回は最初期から構築するということで個人開発者向けにお財布や環境を守るうえでの最初にやったほうがよい課金のセーフティ的な設定をまとめていきたい

        個人開発者がGoogle Cloudの環境構築でお財布を守るために最初にすべきこと - Qiita
      • プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術

        プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術 2024年3月5日 株式会社サイバーエージェント インフラエンジニア 青山真也 (Masaya Aoyama) 2016年、新卒でサイバーエージェントに入社。OpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームをゼロから構築し、国内カンファレンスでのKeynoteに登壇。著書に『Kubernetes完全ガイド』『Kubernetesの知識地図』『みんなのDocker/Kubernetes』。現在はKubernetesやOpenStackなどOSSへのコントリビュート活動をはじめ、CloudNative Days Tokyo Co-chair、CNCF Japan ChapterのOrganizer、Kubernetes Meetup TokyoのOrgani

          プライベートの時間は極力削らない。Kubernetesエキスパート青山真也氏のコスパ最高な情報収集術
        • 日本経済新聞社を退職しました

          業務委託期間を含めて4年在籍した日本経済新聞社を退職しました。 日経に入るまで 自分が日経に入った理由は3つあり、 そろそろ健康保険が切れそうだったから Web標準への理解が求められる仕事をしたかったから 情報を編纂すること、発信すること自体に興味があり、興味と事業ドメインがマッチするから です。なんと自己中な・・・ 前の会社を辞めてフリーランス(と名乗ってはいたがどちらかというと無職の方が実態には近かった)になったときの話も書いておくと、元々は営業から入社した職場で活躍できず逃げるようにエンジニアになったものの、その道で進んでいこうにも未経験で基礎的な能力が無かったので勉強期間を作りたくなって辞めました。当時社会人を経験して思ったのは、社会では期待される人に成長できる仕事が任されていくので、ブートストラップに失敗した自分はこれから常に不利な戦いを強いられ続けそうだということです。なので勉

            日本経済新聞社を退職しました
          • モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話

            こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ

              モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話
            • 機械学習基盤のアーキテクチャ特集 〜8社の設計意図と今後の展望〜 - Findy Tools

              毎回ご好評頂いているアーキテクチャ特集の今回のテーマは、機械学習です。 機械学習に特に力を入れている日本のIT企業8社にご協力頂き、それぞれの技術的な挑戦と今後の展望についてご寄稿頂きました。各社のアプローチと最新の技術動向を通じて、次世代のイノベーションを紐解いていきましょう。 ※ご紹介は企業名のアルファベット順となっております 株式会社ABEJA ABEJA Insight for Retailについて ABEJA Insight for Retailは、お客様の店舗訪問から購入までの行動をデータから分析する、ABEJAが提供するDXツールです。店舗にIoTデバイス(カメラや来客カウンター等)を設置し、取得データを顧客企業に提供することで小売店舗の運営を支援しています。「リアル世界のGoogleAnalytics」をご想像いただけるとわかりやすいかもしれません。ABEJAが取得・提供す

                機械学習基盤のアーキテクチャ特集 〜8社の設計意図と今後の展望〜 - Findy Tools
              • 「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball

                最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー(Continuous Delivery)」とか「DevOps」ってどこから学ぶかわからんな!? というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので(ちゃんと学ぼうとすると). そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな

                  「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball
                • 社内の基盤を活かして爆速開発を実現するために重視したマイクロサービステンプレートの5つの要点 - MonotaRO Tech Blog

                  はじめに 転職後の二つの喪失感への対応 所属チームの現状とMonotaROのアプリケーション/サービス共通基盤(所謂プラットフォーム) 所属チームの状況 社内プラットフォームの状況 マイクロサービス開発のためのテンプレートの導入 開発のロケットスタート:テンプレートの早期提供 テンプレート作成の5つの要点 1. ベンダー非依存なObservabilityの実装 2. CI/CDを早期に提供(特にLinterを最初期に) 3. APIプロトコルとして、JSON over HTTPとgRPCの双方をサポート 4. 最低限の薄いフレームワーク 5. セントラルProtobufリポジトリの提供 現在の取り組み (2023年10月以降)と今後の展開 さいごに はじめに はじめまして、MonotaROのCTO-Officeに所属する伊藤と申します。 github.com recruit.monotar

                    社内の基盤を活かして爆速開発を実現するために重視したマイクロサービステンプレートの5つの要点 - MonotaRO Tech Blog
                  • プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ

                    Darren EvansEMEA Practice Solutions Lead, Application Platform ※この投稿は米国時間 2024 年 5 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 なぜ新しいトピックに対して否定的になってしまう人がいるのか、その理由は、群盲象を評すの寓話からわかります。その人自身の視点からのみで物事を見てしまうと、その全体像を見失ってしまうということです。プラットフォーム エンジニアリングはソフトウェア デリバリーの比較的新しい手法です。現在、IT 組織やソフトウェア エンジニアのチームの多くがプラットフォーム エンジニアリングについて検討している段階にあるのですが、プラットフォーム エンジニアリングとは何なのか、プラットフォーム エンジニアリングで何ができるのか、プラットフォーム エンジニアリングを導入す

                      プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ
                    • 手に職がない35歳エンジニアが如何にしたら転職できるか考えてほしい

                      ※一番下に追記あり 理由社内政治的に言えば負け組に属するし昇給に期待できないのとメンタル面の複合的な理由で頑張り切れなくて成果も出ずモチベーションが下がってる。 今後のベースアップも望み薄な状況になったので給与同水準で今後頑張れそうなところに入りてぇなぁ。 希望現状と同水準の年収500万、それ以上もらえるのならうれしい。 完全リモートワーク。出向などはなし。 ITSとかのまともな健康保険組合に属している。 スキルセットWeb系といえばWeb系。Androidアプリ開発もやってたけど今はWebの運用保守まわり。 就職して10年くらい流れに身を任せてなぁなぁに過ごしてきたので何も身についてる気がしない。 以下のスキルもだいたいが腰をいれてやろうと思えばできる、なレベル。 ・まぁわかる k8s, Java(SpringBoot), PHP(5.3くらいまでの話) 業務でバックエンド周りの保守を触

                        手に職がない35歳エンジニアが如何にしたら転職できるか考えてほしい
                      • モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望 - Findy Tools

                        モバイルゲームの裏側には、最高のプレイ体験を支える高度なインフラ技術があります。 本特集では、「グリー株式会社」「株式会社gumi」「KLab株式会社」「株式会社コロプラ」「株式会社MIXI」の5社のエンジニアの方々にご協力頂き、インフラにおける技術選定のポイントや今後の展望を、アーキテクチャ図と共に解説頂きました。 ※ご紹介は企業名のアルファベット順となっております グリー株式会社 会員限定コンテンツ無料登録してアーキテクチャを見る アーキテクチャ選択の背景や意図 ゲームサービスのクラウドアーキテクチャとして重要な点は、急激な高負荷に対してスケールできることと、サービスのメンテナンス時間を不要にできることの2点でした。そのため、Google Kubernetes EngineとCloud Spannerを主軸に置いた構成となっています。特に、書き込み・読み込みの性能のスケールができ、クラ

                          モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望 - Findy Tools
                        • Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる

                          はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム

                            Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
                          • メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング

                            こんにちは。メルカリ ハロのSoftware Engineer (Engineering Head)の@napoliです。連載:Mercari Hallo, world! -メルカリ ハロ 開発の裏側-の2回目を担当させていただきます。 2024年3月上旬にメルカリ ハロという新しいサービスが公開されました。メルカリ ハロは好きな時間に最短1時間から働ける「空き時間おしごとアプリ」です。 この記事ではメルカリ ハロを作るにあたり、どういった技術スタックやアーキテクチャを選定したのか、さらにその背景と意思決定をご紹介したいと思います。 この記事で得られること メルカリ ハロで採用されている技術スタックやアーキテクチャの全体像 その意思決定の理由とプロセス これから新規サービスを立ち上げるうえでのヒント 主な技術スタック メルカリ ハロで利用されている主な技術スタックは以下のとおりです。 バッ

                              メルカリ ハロの技術スタックとその選定理由 | メルカリエンジニアリング
                            • 【総額350万】高額請求がきたエンジニアの失敗から学べること - Qiita

                              はじめに 成功よりも失敗を学ぶ方が再現性が高く成果を出しやすい これは私がアウトプットをする上で常に心がけていることです。 あなたは普段自分の経験や体験を記事として発信しているでしょうか? おそらく多くの人ができていないはずです。 今回は私が過ごしてきたエンジニア人生4年の中で、特に大きかった失敗談をまとめて紹介していきます。 それぞれの失敗談の詳細はリアルタイムに記事を投稿しているので、ぜひ気になった方は最後にリンクを載せていますので確認いただけると良いかと思います。 この記事はQiita Engineer Festa 2024 〜しくじりエンジニア!私みたいになるな!~の登壇内容を記事にまとめたものになります。 失敗こそアウトプットせよ 「成功よりも失敗を学ぶ方が再現性が高く成果を出しやすい」という言葉の通り、成功は人それぞれバックグラウンドが違っていたり、運も絡んでいるので再現性は低

                                【総額350万】高額請求がきたエンジニアの失敗から学べること - Qiita
                              • チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog

                                はじめに チームトポロジーとは プラットフォーム開発組織に存在した課題 SRE何でも屋問題 中長期課題に取り組めない問題 チームトポロジーを元にした組織見直し SRE Deskを3つのDeskに分割 SRE DeskとPlatform Engineering Deskの違いを明文化 見直しの効果 見直しを通じての所感 最後に はじめに こんにちは。enechainでCTOを務めている@sutochin26です。 enechainでは、組織拡大に伴いSRE/Platform関連業務を行うチームの体制見直しを行ないました。 その際に、チームトポロジーの考え方を参考にする事で方針の言語化がしやすくなり、認識合わせの助けになりました。 SREとPlatform Engineeringをチームトポロジー視点で定義すること自体は新しくはないですが、本記事では実際に現場で生じていた課題と共にお話します。

                                  チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog
                                • SLOの導入は早ければ早いほどよい 〜FAANSの事例とその効果〜 - ZOZO TECH BLOG

                                  はじめに こんにちは、FAANS部バックエンドブロックでFAANSのバックエンドシステムの開発と運用をしている田島です。 2021年11月にZOZOTOWNとアパレルのブランド実店舗をつなぐOMOプラットフォーム「ZOZOMO」が始動しました。FAANSは、ZOZOMOで展開するサービスの1つで、ブランド実店舗で働くショップスタッフ専用の販売サポートツールです。FAANSは2022年8月の正式版リリース以来、これまで様々な機能をリリースしてきました。以下はその一部です。 投稿機能: ショップスタッフが自身で自社のアイテムを着て撮ったコーディネート画像やコーディネート動画といったコンテンツを複数チャネルに同時投稿できる機能。投稿先チャネルとしては、ZOZOTOWNやWEAR、Yahoo!ショッピングといった弊社並びに弊社のグループ会社のWebサイトだけでなく、ブランド企業の自社ECサイトへの

                                    SLOの導入は早ければ早いほどよい 〜FAANSの事例とその効果〜 - ZOZO TECH BLOG
                                  • 大規模サービスの負荷試験を改善していった話

                                    こんにちは!株式会社COMPASSのシステム開発部、SREチームのごーすと(@5st7)です!普段は、k8s周りの運用であったり、アプリケーションのパフォーマンスの監視、改善、インフラ周りの自動化などを積極的に進めています。三度の飯よりも好きなものがプリンで、美味しいプリンの店とかが流れてきたら1営業日以内に馳せ参じます。プリン好きな人はお店で会いましょう。 今日は負荷試験の取り組みについてご紹介できればと思います。COMPASSが提供するキュビナは現在100万人を超えるユーザーに利用していただいていますが、その分トラフィックも大きく、安定してサービスを提供できるようにするために、様々な工夫をしています。その中でも利用の集中する時間帯の負荷に耐えられるかの検証は非常に重要な取り組みの一つです。今回は、COMPASSが今まで負荷試験にどのように取り組んできたのか、その歴史と改善を行っていった

                                      大規模サービスの負荷試験を改善していった話
                                    • Kubernetes History Inspector(KHI)でたわむれる

                                      Google Cloud Japan のRyuSAです💪 Kubernetes は大変便利です。多くのコンテナを論理的にまとめてデプロイしたりノードのオートスケールのエコシステムが充実していたり、昨今のクラウドネイティブな環境においてなくてはならない存在です。 しかし便利である一方その挙動は複雑です。Pod をデプロイするだけでも内部的には kube-scheduler や kubelet、containerd など複数のプロセスが関与し、トラブルシューティングするためには様々なログやステータスを確認しなくてはいけません。 Kubernetes History Inspector は Google Cloud リポジトリで公開されたOSS で、Kubernetes の監査ログなどを元に特定の時間枠で Kubernetes 内で起きていたイベントをタイムライン化、オブジェクトのヒストリーを

                                        Kubernetes History Inspector(KHI)でたわむれる
                                      • OpenSSH の脆弱性について

                                        こんにちは、クラウドエースの SRE チームに所属している妹尾です。 今回は OpenSSH の脆弱性についての記事です。 (この記事は 7/4 に速報版から正式版へ更新しました) 2024/07/02 に、CVE-2024-6387が発表されました。 これは放置しておくと SSH を受け付ける全てのサーバーを乗っ取る事ができてしまう脆弱性です。 厄介なことにデフォルト設定の SSH-Server と、ある程度の時間があればサーバーを乗っ取れてしまうので、緊急度もかなり高めになっております。 そして Compute Engine もこの影響を受ける ので、多くの環境で対策が必要となります。 結局どうすればいいの Google が公表している、 GCP-2024-040 の手順に従いましょう。 (日本語訳ページだとまだ公表されてないようですので、英語版を見てください) 具体的には、以下のよう

                                          OpenSSH の脆弱性について
                                        • AI・機械学習チームで学んだ開発技法で趣味の通知系ツールを量産した - エムスリーテックブログ

                                          AI・機械学習チームブログリレー 7日目担当の高田です。 AI・機械学習チームでは、開発するプロダクトの数が多く、スピード感を持って開発を進めることが求められます。 そのような環境の中では、高速にプロダクトを生むためのあるあるのアーキテクチャであったり、どのプロダクトでも使っているぞというライブラリが存在します。 それらのノウハウを活かして、日曜大工で作った趣味開発のプロダクトを紹介していきたいと思います。 AI・機械学習チームのあるある アーキテクチャ編 ライブラリ編 趣味プロダクトもスピードが大事 YouTubeライブ開始通知 ポイ活案件検知 ANAトクたびマイル通知 まとめ We're hiring! AI・機械学習チームのあるある アーキテクチャ編 例えばm3.com会員向けのコンテンツ配信設定など、ビジネスサイドでデータの入力を運用するプロダクトがあります。そういったプロダクトで

                                            AI・機械学習チームで学んだ開発技法で趣味の通知系ツールを量産した - エムスリーテックブログ
                                          • GKE/EKS(Kubernetes)のコスト可視化を良い感じにしてみた - MonotaRO Tech Blog

                                            はじめに こんにちは!コンテナ基盤グループの楠本です。 今回はマルチテナント運用におけるKubernetesクラスタ内のコスト把握方法についてご紹介します。 見どころは EKSでKubecostを使ってみたがうまくいかなかったこと OpenCostを導入して解消したこと Datadogを使ってマルチクラウドのKubernetesを把握できるようにしたこと の3点です。 はじめに 結果:OpenCost・Datadogを使って出来たもの EKSにKubecostを試験導入してみた スプレッドシートで頑張っていた頃 EC2にかわって出番が回ってきた 過去分は取得できない EBSボリュームの管理 EBSボリュームタイプ レポート出力 インスタンスの割引率 Kubecostに躓いた コストに対するモチベーション OpenCostでリトライ 必要なものはOpenCostとPrometheus Pro

                                              GKE/EKS(Kubernetes)のコスト可視化を良い感じにしてみた - MonotaRO Tech Blog
                                            • OpenTelemetry Collector導入の実践編とその後 - Gaudiy Tech Blog

                                              はじめまして。Gaudiyでエンジニアをしているあんどう(@Andoobomber)です。 以前、「OpenTelemetry Collector導入のPoCと今後に向けて」という記事を弊エンジニアの sato(@yusukesatoo06)より公開しました。簡単に記事を要約すると、 OpenTelemetry及びOpenTelemetry Collectorの説明 実際にPoCを作ってみる 実導入を試みたがOpenTelemetry Collectorのホスティングに悩み、今後の課題として保留となった といった内容でした。 あれから1年経ち、GaudiyではOpenTelemetry Collectorを本番環境に組み込み、OpenTelemetryの仕様に準拠して計装し、データの分析や監視を行っています。この記事では、前回からの進捗を紹介すると共にOpenTelemetryの導入方法を

                                                OpenTelemetry Collector導入の実践編とその後 - Gaudiy Tech Blog
                                              • EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog

                                                はじめに こんにちは!コンテナ基盤グループの楠本です。 前回の記事EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blogを投稿してから半年以上も経ちました。(時が流れるのは早い… 前回はSREグループコンテナ化推進チームとしてでしたが、今回は挨拶の通りコンテナ基盤グループとしての投稿です。 元々ECエンジニアリング部門のSREグループとして活動していましたが、今年初めに組織編成があり、プラットフォームエンジニアリング部門の1グループとして活動しています。 今回は組織とのミスマッチからEKS on FargateからEKS on EC2へ切り替えた話をご紹介します。 見どころは EKS on Fargateとプラットフォームエンジニアリングとの相性 EKS on EC2へ移行する際に検討したこと 移行して得られたこと の3点です

                                                  EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog
                                                • NetworkPolicyでtrafficを制御しよう - enechain Tech Blog

                                                  はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri

                                                    NetworkPolicyでtrafficを制御しよう - enechain Tech Blog
                                                  • 「図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書[改訂2版]」をより効果的に読むポイント

                                                    「図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書[改訂2版]」をより効果的に読むポイント 「図解即戦力 Google Cloud のしくみと技術がこれ 1 冊でしっかりわかる教科書」とは Google Cloud の基礎知識が学べる「図解即戦力 Google Cloud のしくみと技術がこれ 1 冊でしっかりわかる教科書」が、2024 年 9 月 (電子書籍版は 8 月) に出版されました。 こちらの書籍は Google Cloud のパートナーエンジニアと Google Cloud のパートナーである grasys さんの共著となっており、実際に Google Cloud を現場で使用しているプロフェッショナルの視点で初学者・中級者向けに書かれています。そのため、本書は これから業務で Google Cloud を使用する上で必要な知識 がまとめられた

                                                      「図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書[改訂2版]」をより効果的に読むポイント
                                                    • 【Kubernetes】未経験から1か月経ったので振り返る - APC 技術ブログ

                                                      こんにちは、クラウド事業部の中根です。 未経験からKubernetesに入門して約1か月が経ったので、振り返りたいと思います! 実務に入る前の予習なので、実務を通した実践的な学習はしていない点はご了承ください。 学習の動機 入門前のレベル感 学習プロセス 入門0~7時間 入門7~32時間 入門32~60時間目 入門60~71時間目 入門71~132時間目 +α できるようになったこと 次のステップ これから入門する方へ おわりに お知らせ 学習の動機 私は中途入社で、案件は決まったのですが、参画まで1か月半ほど待機期間となりました。 クラウドネイティブな案件ということで、この期間を活かしてKubernetesのキャッチアップをすることになりました。 入門前のレベル感 IT業界経験が3年と1か月です。 以下、関係する領域の詳細です。 Kubernetes ほぼ未経験。 OpenShiftをち

                                                        【Kubernetes】未経験から1か月経ったので振り返る - APC 技術ブログ
                                                      • 現場から学ぶMLOps: MonotaROでの実践的アプローチ~オンライン推論編~ - MonotaRO Tech Blog

                                                        はじめに こんにちは。MonotaROで機械学習エンジニア兼、Tシャツのモデルを務めている新卒3年目の長澤です! 最近は健康のためにスポーツをしているのですが、そのスポーツの疲れで日々が辛くなってきました。観戦と自分で身体を動かす方の割合(重み)をバンディットを使ってうまく最適化していきたいこの頃です。 今回は、自分がここ1,2年(2023~2024)で取り組んできたMonotaROにおけるMLOpsの取り組みについて、実例を交えながら紹介します。MLOpsの実例はあまり世の中に出回っていないので、一つの事例として読んでもらえれば嬉しいです。 はじめに この記事で紹介すること この記事で紹介しないこと MonotaROにおける機械学習エンジニア パーソナライズドランキングとは MLOpsに取り組むにあたっての背景と課題 MLOpsのプロジェクトスタート時 MLOpsとりあえず始めてみる期

                                                          現場から学ぶMLOps: MonotaROでの実践的アプローチ~オンライン推論編~ - MonotaRO Tech Blog
                                                        • モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog

                                                          こんにちは、プラットフォームエンジニアリング部門コンテナ基盤グループの岡田です。 当社ではECサイトの裏側で利用されているモノリシックなAPIをコンテナ化し、Elastic Kubernetes Service (EKS) に移行しました。 移行直後は下記のようにトラブルに見舞われましたが、現状安定した運用ができています。 EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog 今回はトラブル事例ではなく活用事例になりますが、アプリケーションリリース起因でのトラブル影響を減らすため、コンテナ化したAPIに対してカナリアリリース導入を行いました。そのため、導入に際して生じたConfigやSecret周りの課題

                                                            モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog
                                                          • Streamlit × GKE で構築する社内向けツール - enechain Tech Blog

                                                            この記事はenechain Advent Calendar 2024の10日目の記事です。 はじめに enechain データサイエンスデスク エンジニアの藤村です。 我々データサイエンスデスクは、電力や燃料に関するデータ分析や予測モデルの構築などの他に、enechainの様々なビジネスをサポートする社内向けツールの開発・運用も行っています。機械学習や数理最適化を活用したアプローチを中心に、最近ではLLMの活用にも取り組んでいます。 本稿では、この取り組みでStreamlitアプリケーションをGKEでホストするに至った経緯や、その運用について紹介します。 なぜ Streamlit なのか 社内の業務を支援するツールを構築する際、常に課題となるのが「人間の判断をどのように介在させるか」という点です。ドメインやアルゴリズムの性質上、自動化が難しい部分も多く、人間の判断を介在させる必要のある場面

                                                              Streamlit × GKE で構築する社内向けツール - enechain Tech Blog
                                                            • Megatron-LMとGKEで作るMixtral 8x7Bを語彙拡張継続事前学習 Part1 ~学習コードとモデルの先行公開~ - ABEJA Tech Blog

                                                              こんにちは!ABEJAでデータサイエンティストをしている大谷です。 ABEJAは国立研究開発法人新エネルギー・産業技術総合開発機構(以下「NEDO」)が公募した「ポスト5G情報通信システム基盤強化研究開発事業/ポスト5G情報通信システムの開発」に当社提案の「LLMの社会実装に向けた特化型モデルの元となる汎化的LLM」が採択されたことを受け、LLMの事前学習を実施しました。 以降、本LLMプロジェクトをGENIAC(Generative AI Accelerator Challenge)と表記します。 開発内容は表題の通り、Mistral社のMIxtral 8x7Bをベースにした日本語の語彙拡張版継続事前学習です。弊社が調べた限り、Megatron-LMでMixtralモデルを継続事前学習するソースコードは2024年4月12日時点(執筆時)では存在していません。 GENIACの計算資源提供の

                                                                Megatron-LMとGKEで作るMixtral 8x7Bを語彙拡張継続事前学習 Part1 ~学習コードとモデルの先行公開~ - ABEJA Tech Blog
                                                              • Host your LLMs on Cloud Run | Google Cloud Blog

                                                                Run your AI inference applications on Cloud Run with NVIDIA GPUs Developers love Cloud Run for its simplicity, fast autoscaling, scale-to-zero capabilities, and pay-per-use pricing. Those same benefits come into play for real-time inference apps serving open gen AI models. That's why today, we’re adding support for NVIDIA L4 GPUs to Cloud Run, in preview. This opens the door to many new use cases

                                                                  Host your LLMs on Cloud Run | Google Cloud Blog
                                                                • SREチーム強化の新たな手段 ~協業で実現する信頼性向上~ - enechain Tech Blog

                                                                  はじめに こんにちは。enechainのPlatform EngineeringチームSoftware Engineerの soma00333 です。 enechainは電力の卸取引や環境価値の取引の機会を提供するマーケットプレイスを運営する会社で、インフラ基盤としてGKEを採用しています。信頼性が非常に大切なドメインで、SREの力が欠かせないビジネスを展開しています。 この度、enechainはSREチームのさらなる強化を目指し、SRE as a Serviceを提供する 株式会社Topotal様 にご支援いただいて新たに2名のエンジニアを迎えました。 SREチームを強化するにあたり、「採用を頑張る」「内部で育てる」など手段は様々です。 本記事では、「外部会社(Topotal様)との協力」という手段がSREチーム・開発チーム全体にどのような効果をもたらしているかを紹介します。 SREチー

                                                                    SREチーム強化の新たな手段 ~協業で実現する信頼性向上~ - enechain Tech Blog
                                                                  • 「絶妙に妥協」した電力取引プラットフォームeSquare Liveの開発の裏側 - enechain Tech Blog

                                                                    はじめに eSquare Liveの特徴 リアルタイム取引 自動で約定するマッチングエンジン 3種類の画面を作る必要性 爆速開発スピードと品質を両立したeSquare Liveのエンジニアリング 技術的なOverview 主な技術スタック 「絶妙に妥協」したアーキテクチャ monorepo k6を利用した負荷試験 意思決定に利用したADR 今振り返っての反省点 メンバー構成 仕様書の保守、QAの進め方 今後の展望 お知らせ はじめに こんにちは!enechainでプロダクト開発部の部長を務める長谷川です。 enechainは2024年10月9日にeSquare Liveという電力卸取引のオンライン取引マーケットプレイスをローンチしました。 eSquare Liveは、簡単に言うと株取引で利用するような板画面上で電力の卸取引ができるプラットフォームです。 電力のトレーダーは、このプラットフォ

                                                                      「絶妙に妥協」した電力取引プラットフォームeSquare Liveの開発の裏側 - enechain Tech Blog
                                                                    • We’re leaving Kubernetes - Blog

                                                                      Kubernetes seems like the obvious choice for building out remote, standardized and automated development environments. We thought so too and have spent six years invested in making the most popular cloud development environment platform at internet scale. That’s 1.5 million users, where we regularly see thousands of development environments per day. In that time, we’ve found that Kubernetes is not

                                                                        We’re leaving Kubernetes - Blog
                                                                      • データメッシュを意識したBigQueryのデータ管理設計 - enechain Tech Blog

                                                                        この記事は enechain Advent Calendar 2024 の12日目の記事です。 はじめに こんにちは! enechain でデータプラットフォームデスクのEMをしている26Takafujiです。 私は2023年9月にenechainへジョインし、そこからちょうど1年強の時間が経ちました。 入社時はまだ全社横断のデータ基盤は検討中の段階で本格的な提供はこれからという状態でしたが、この1年間でデータ基盤としての1st Stepである「まずはデータを集める」を進めてきて、主要なデータソースのBigQueryへの集約を一通り仕組み化できました。 今回は進めてきた仕組み化の中で、データ界隈では数年前から巷でよく取り上げられる「データメッシュ」の概念を念頭においた時、BigQueryへ集約されたデータの管理をどういった形で考えたのかを書いてみたいと思います。 これからデータ基盤を構築し

                                                                          データメッシュを意識したBigQueryのデータ管理設計 - enechain Tech Blog
                                                                        • Cloud Run のサービスメッシュを試した

                                                                          Cloud Run のサービスメッシュを試した 以前から GKE では Cloud Service Mesh を使ってサービスメッシュを利用することができましたが、Cloud Run でもサービスメッシュを利用できるようになりました(作成時点の2024-09-02ではプレビュー段階)。 この記事ではサービスメッシュならではの機能をサンプルアプリを使って確認します。 検証シナリオ 検証環境の構成 サンプルアプリとして Istio のドキュメントに掲載されている bookinfo (本の情報やレビューが見られる Web アプリで、マイクロサービスで実装されている)のコンテナイメージを利用します。 検証する機能 下記の4点について確認を行います。 サービス間の認証、認可を自動的に行う 従来の Cloud Run では ID トークンを明示的にヘッダに付与してリクエストを送信する必要があり、アプリ

                                                                            Cloud Run のサービスメッシュを試した
                                                                          • Kubernetes Pod の IP アドレスが枯渇しかけている場合に役立つ実証済みの解決策を紹介 | Google Cloud 公式ブログ

                                                                            Gemini 1.5 モデル をお試しください。Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。 試す ※この投稿は米国時間 2024 年 4 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 Kubernetes の大きな強みの 1 つは、Pod ごとに固有のネットワーク アドレスがあることです。これにより、Pod が VM のように機能するため、デベロッパーはポートの競合などの煩わしい問題を気にする必要がありません。Kubernetes のその特性のおかげで、デベロッパーやオペレーターは作業を簡略化できます。また、設計機能の 1 つとして高い信頼性を獲得しているため、コンテナ オーケストレーターとしての人気が非常に高くなっています。Google Kubernetes Engine(GKE)は、VPC 内

                                                                              Kubernetes Pod の IP アドレスが枯渇しかけている場合に役立つ実証済みの解決策を紹介 | Google Cloud 公式ブログ
                                                                            • 高速な仮説検証を支えていくHasuraの導入 - enechain Tech Blog

                                                                              はじめに eScanチームの平田です。 eScanは日本の電力事業に特化したリスク管理サービス(ETRMシステム)です。2022年から開発を始め、お陰様で今では徐々に導入いただける社数も増えてきています。まだまだ不足している機能はありますが、すべてのお客様が確実に必要とするであろうETRMの必須機能の実装は概ね終わっており、新規機能追加中心フェーズは終わりつつあります。これからは、よりお客様にとって価値のあるサービスになるような機能強化や改善を中心にする必要があると考えています。 今回は、eScanチームでの事業フェーズの変化に伴う開発プロセスの試行錯誤と、高速な仮説検証の補助として導入を進めているHasuraについてお話します。 フェーズの変化と仮説検証の必要性 「はじめに」に記載したとおり、徐々に新規機能追加中心のフェーズからより顧客への提供価値の最大化を目指すフェーズに差し掛かってい

                                                                                高速な仮説検証を支えていくHasuraの導入 - enechain Tech Blog
                                                                              • AIチームGoogle Kubernetes Engineオンボーディングチュートリアル - エムスリーテックブログ

                                                                                こんにちは。AI・機械学習チーム(以下AIチーム)チームリーダー、兼、エンジニアリンググループゼネラルマネージャーの横本(@yokomotod)です。 AIチームでは開発したMLプロダクトの実行基盤としてGoogle Kubernetes Engine(以下GKE)を採用しています。デプロイ関連コードのテンプレートも整備され、新しいプロダクトをスタートさせるときはGKE初心者でも簡単にデプロイまで持っていけるようになっています。 しかし自動生成は一方で、なにがどうなってデプロイされているのかブラックボックスのままになってしまいがちという問題もあります。 そこで今回は、チームメンバーへのオンボーディング、そしてKubernetesを触ってみたい人の参考になればと期待して、 ゼロからGKEにデプロイするハンズオン形式のチュートリアルを作ってみました。 What's this 前提条件 GKEク

                                                                                  AIチームGoogle Kubernetes Engineオンボーディングチュートリアル - エムスリーテックブログ
                                                                                • KubernetesとPyTorch Lightningによる医療AI開発環境とそのTips - エムスリーテックブログ

                                                                                  こちらはエムスリー Advent Calendar 2024 5日目の記事です。AI・機械学習チームの三浦 (@mamo3gr) が、深層学習に基づく医療AIの開発環境とTipsについてお送りします。 DALL-E 3が生成した「巨大クラスタによるAI開発」のイメージ図 Kubernetesクラスタよる医療AIの開発 モデルの性能改善に注力できるフレームワークPyTorch Lightning デバイス特有のコードを書かなくてよい 学習ログやチェックポイントの保存機能が充実している 細かなユーティリティ関数やクラスの実装がある ハマりポイントとワークアラウンド 学習ログファイルを正しく保存する 学習を継続実行する まとめ We are hiring !! エンジニア採用ページはこちら カジュアル面談もお気軽にどうぞ インターンも常時募集しています Kubernetesクラスタよる医療AIの

                                                                                    KubernetesとPyTorch Lightningによる医療AI開発環境とそのTips - エムスリーテックブログ