タグ

nnhrskのブックマーク (707)

  • Kubernetes ベスト プラクティス 6 選 | Google Cloud 公式ブログ

    ※この投稿は米国時間 2020 年 1 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。 数年前、Kubernetes はコンテナ化されたアプリケーションの管理をサポートし、大いに注目を集めました。今では、番環境でのアプリケーションの大規模なデプロイや管理に広く使用されています。その過程で私たちは、KubernetesGoogle Kubernetes Engine(GKE)を最大限に活用するためのヒントやベスト プラクティスを収集してきました。ここでは、Kubernetes のデプロイと利用方法に関する Google Cloud ブログのなかから、最も人気の高い記事の一部をご紹介します。 リソース管理を容易にする Kubernetes の Namespace : Kubernetes 上でサービスを構築すると、単純なタスクが複雑になっていきます。一種

    Kubernetes ベスト プラクティス 6 選 | Google Cloud 公式ブログ
  • Network overview  |  Google Kubernetes Engine (GKE)  |  Google Cloud

    Accelerate your digital transformation Whether your business is early in its journey or well on its way to digital transformation, Google Cloud can help solve your toughest challenges.

    Network overview  |  Google Kubernetes Engine (GKE)  |  Google Cloud
  • Envoy と Kubernetes で始める Progressive Delivery - Qiita

    記事は 2020/01/08 に開催された Envoy Meetup Tokyo #1の LT スライド兼補足資料です。 原則として、スライドモードでファーストビューに入るものはスライドとして、下にスクロールして表示される部分は補足資料です。 Progressive Delivery とは Continuous Delivery ++ 実装はたいてい Canary Release + Canary Analysis + Automated Rollback "Progressive Delivery is the next step after Continuos Delivery, where new versions are deployed to subset of users and are evaluated in terms of correctness and perfor

    Envoy と Kubernetes で始める Progressive Delivery - Qiita
  • Dockerコンテナ時代の第二章~Kubernetesの成熟とエコシステム発展の時代

    Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。 その様子は2017年12月に公開した記事「Dockerコンテナ時代の第一章の終わり、そして第二章の展望など」で紹介しました。 この記事の公開から2年が経過し、現在のコンテナ型仮想化技術は、マイクロサービスやクラウドネイティブなどの文脈とともにエンタープライズな分野でも使われるメインストリームな技術へと確実に進み続けています。 記事では前記事で描いたDockerコンテナ時代の第一章に続く第二章として、コンテナ型仮想化技術のここ2年半ほどの動向をPublickeyなりにまとめてみました。 Docker 1.0の到達とKubernetesの登場 まずはDockerKubernetesの登場とその後の主要

    Dockerコンテナ時代の第二章~Kubernetesの成熟とエコシステム発展の時代
  • サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019

    原 康紘 アマゾン ウェブ サービス ジャパン株式会社 技術統括部 ソリューションアーキテクト AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。 AWS の詳細については http://aws.amazon.com/jp

    サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019
  • Kongにジョインしました - ikeike443のブログ

    ジョインしました、というのはかなり正確な表現です。Kongはまだ日法人がないため、契約上は業務委託となっているので、入社というのはちょっと違うからです。 法人もなければまだオフィスもないので、今のところ私の自宅がKong Japanです。 Kongはサンフランシスコに拠点を置く会社で、APIゲートウェイ、KubernetesIngress controllerおよびService meshの領域で複数のOSSとそのエンタープライズ・ソリューションを提供している会社です。競合はApigeeやMulesoftと言われることもありますが、むしろLinkerdや最近Service meshみが著しいConsulあたりになっていくかもしれない雰囲気を出し始めていて、なかなか面白いことになりそうだと感じています。(Istioも競合になり得るかもしれないけど、今はむしろ協調して使ってもらうイメージを

    Kongにジョインしました - ikeike443のブログ
    nnhrsk
    nnhrsk 2020/01/03
    理想はこれだよなぁ - “サービスメッシュは大きなアーキテクチャの移行を実施し始める前に導入すべきです。"
  • 令和時代に「Spring入門」「Spring徹底入門」を読むとき気をつけるべきN個のこと - Qiita

    この記事について 事ある度に書いたり言ったりしている通り、2020年を迎えようとしている現在でも、信頼できるSpring関連書籍は下記の2冊しかありません。 Spring徹底入門 改訂新版Spring入門 2冊(以下「書籍」)とも超良書なのですが、どちらもリリースされたのが2016年で、対応しているSpringのバージョンが4.2と古くなっています。 2019年末時点での最新版はSpring 5.2です。この記事では、上記書籍を令和の今読む際、特に気をつけるべき点をいくつか紹介していきます。 4.x->5.xの差分すべてについては、GitHubのWikiを確認してください。 JDKは8以上を使うべし Spring 5.0以降から、JDKのベースラインが8になりました(Spring 4はJDK 6ベース)。今からSpringを使おうと言う人が、JDK 6とか7を使おうとはしないと思いますが・

    令和時代に「Spring入門」「Spring徹底入門」を読むとき気をつけるべきN個のこと - Qiita
  • 働きながら米国のコンピュータサイエンスの学士号を取得する、UoPeopleという選択肢 - Velocity

    2019年もついに終わりを迎え、2020年になろうとしている。 6月末に転職してから半年が経った。 SESから自社開発になり、自分の動き方・考え方も少しずつ変化したように感じられる。 技術的な部分だけではない、前職とはまた違った観点でエンジニアリングそのものの難しさを実感している。 しかし、自社開発ならではのサービスとチームの距離の近さは素晴らしく、一つ一つサービスを良くしている実感を得られるのはやはり楽しい。 同僚も優秀な方ばかりで、転職して良かったと心から思う。 一方で、この半年で心の奥底からふつふつと湧いてきたものもあった。 コンピュータサイエンスへの興味だ。 コンピュータサイエンスへの憧れ 僕は工業高校を卒業してからすぐ、石油天然ガスのプラントに就職。 その後、1年半でベンチャー企業(SES)に転職。 そして再び1年半後、現職(Webサービス開発)に転職、という経歴を持っている、2

    働きながら米国のコンピュータサイエンスの学士号を取得する、UoPeopleという選択肢 - Velocity
    nnhrsk
    nnhrsk 2019/12/31
  • JVMのヒープサイズとコンテナ時代のチューニング | Folioscope

    最近 JVM のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ

    nnhrsk
    nnhrsk 2019/12/30
    Java10からUseContainerSupportとMaxRAMPercentage
  • プラットフォームの上でものを作るということ

    プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.

    プラットフォームの上でものを作るということ
  • 段階的に理解する O/R マッピング - Qiita

    はじめに O/R マッピングとは O/R マッピングとは、一言で言えば、オブジェクト指向プログラミング言語においてリレーショナルデータベースのレコードを通常のオブジェクトとして操作する方法である。より詳細な定義を述べるより、実際のコードを見たほうがわかりやすいだろう。以下に、低レベルの JDBC API の利用例と、高レベルの O/R マッピングフレームワークの代表格である JPA の利用例を挙げる。 public List<Issue> findByProjectId(long projectId) { String query = "select id, title, description from issue where project_id = ?"; try (PreparedStatement ps = connection.prepareStatement(query))

    段階的に理解する O/R マッピング - Qiita
  • webエンジニアがシリコンバレーの観光紹介する - Qiita

    はじめに ハイテク企業のメッカとして名高いシリコンバレー、エンジニアとして昔から一度は訪れてみたいと思ってました。そんな私が現地に知り合いゼロ、準備なし初めての渡米で観光してきましたのでその経験を元に観光紹介します。 エンジニア向け観光地に行ってみよう Apple社 おすすめ度 ☆☆ 言わずと知れたアップル社です。建物内には入れず外から見るだけになりますが、映画等にも幾度と登場しているので見たことあると言う人も多いはず。あーこれこれ!と言うやりとりで一瞬盛り上がることができます。 アップルストアが隣接しておりお土産も買えます。ここでしか見たことないグッズも売ってました。 ギザカッコ良すTシャツ Apple社 おすすめ度 ☆☆☆ その未来的デザインから「宇宙船」と呼ばれているアップルの新社屋になります。場所は旧社から少し離れたところにあります。残念ながら部外者は建物内はもちろん、

    webエンジニアがシリコンバレーの観光紹介する - Qiita
    nnhrsk
    nnhrsk 2019/12/22
    楽しそう、行ってみたい
  • 『ダイの大冒険』来秋28年ぶり完全新作で再びアニメ化 ドラクエ世界観の人気漫画が原作

    【写真】その他の写真を見る 同誌で1989年から96年まで連載された同作は、魔法が苦手だが勇者に憧れている主人公・少年のダイが、ある日、島を訪れた“勇者育成の家庭教師”アバンに才能を認められ、勇者になる特訓をする。そして、秘められた力を開花させ、アバンの弟子・ポップ、マァムら仲間とともに復活した魔王を倒し平和を取り戻すべく旅に出る冒険活劇。 同誌の歴代最大発行部数653万部を突破した1995年新年3・4号合併号に『ドラゴンボール』『スラムダンク』『るろうに剣心』『ジョジョの奇妙な冒険』らとともに掲載されており、ジャンプ黄金期を支えた作品のひとつとして知られている。単行の累計発行部数は4700万部を突破している。 人気ゲーム『ドラゴンクエスト』シリーズの世界観・設定を基にしたゲーム作品シリーズと繋がりのない完全オリジナルの世界観で、『ドラクエ』シリーズの生みの親・堀井雄二氏が漫画の監修を担

    『ダイの大冒険』来秋28年ぶり完全新作で再びアニメ化 ドラクエ世界観の人気漫画が原作
    nnhrsk
    nnhrsk 2019/12/21
    履きつぶしてきた靴の数と同じだけの夢たち
  • プロダクトが進捗していないと感じた時の戦い方 - hikoharu's blog

    この記事は Product Manager Advent Calendar 2019の18日目 です。 はじめに プロダクト作りにおける負債の種類 技術的負債 組織的負債 関係者的負債 思想的負債 負債の誕生 影響し合う負債の恐ろしさ 地道に負債を解きほぐしていく おわりに はじめに Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。 スタートアップの強みはストラテジーと実装の一致 早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、

    プロダクトが進捗していないと感じた時の戦い方 - hikoharu's blog
    nnhrsk
    nnhrsk 2019/12/18
    “組織的負債 ”、 "関係者的負債"、"思想的負債"
  • マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ

    「マイクロサービスとメッセージングのなぜ [概要編]」はこちらです。 レッドハットでインテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 概要編ではメッセージングの良い面ばかりに焦点を当ててきましたが、今回の疑問編ではメッセージングを検討し始めたときに疑問に思ったり困りがちなことを説明したいと思います。概要編とは異なり、細かな技術的内容も含まれますので、その時々で必要な部分や興味ある部分だけ読んでいただければと思います。 (ところで、当初は前回を前編、そして今回を後編にして終わらせようと思っていたのですが、今回もあまりに長くなってしまったので、構成を変えたのでした。 このため当初の前編は概要編と名前を変更しています。) ではまず主に疑問とされることを確認して、その後に対処法を見ていきましょう。 メッセージングを利用することによる主な疑問 対処方法 Q1:

    マイクロサービスとメッセージングのなぜ [疑問編] - 赤帽エンジニアブログ
  • ライブドアブログが15年かけて積み上げた技術的負債への挑戦––LINEのブログサービスのエンジニアが明かす、光と影

    ライブドアブログが15年かけて積み上げた技術的負債への挑戦 LINEのブログサービスのエンジニアが明かす、光と影 Inside of Blog 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦 #1/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINE技術の深堀りを、2日目は「Production」をテーマに、Web開発技術UI/UXプロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」に登壇したのはLINE 開発Bチームの大森貴博氏。前半パートとなる今回は、今年で3

    ライブドアブログが15年かけて積み上げた技術的負債への挑戦––LINEのブログサービスのエンジニアが明かす、光と影
    nnhrsk
    nnhrsk 2019/12/17
  • アプリケーションにおけるデータ不整合との戦い - blog.syfm

    これは Aizu Advent Calendar 2019 の 15 日目の記事です。14 日目は uzimaru0000 さん、16 日目は kacky__917 さんです。 はじめに 世の中には日々たくさんの価値ある Web サービスが生まれていますが、その価値を正しく提供するにはアプリケーションが正しく動かなければなりません。 たとえばアプリケーションは適切なユーザに適切なリソースを提供しなければならず、エラーを返す際は十分に定義された仕様に沿って返し、UI 側ではユーザに適切なメッセージを表示しなければなりません。 実際のところ、これらを厳密に実現するのは非常に困難ですが、アプリケーションにはこれら以上に複雑な問題が常につきまといます。 現在の Web アプリケーションはほとんどが分散システムの一形態です。例えばクライアントとサーバや、サーバとデータベースがネットワークを介して接続

    アプリケーションにおけるデータ不整合との戦い - blog.syfm
    nnhrsk
    nnhrsk 2019/12/16
    “ステートマシンパターン”、"Asynchronous Repair"、"データ競合の回避"、"TCC パターン"
  • Kubernetesをぶち壊す10の奇妙な方法 (前編) - Qiita

    はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 12日目のエントリーです。 今回はKubeConに参加して面白かったセッションの1つである「10 weird ways to blow up your Kubernetes(Kubernetesをぶち壊す10の奇妙な方法)」をご紹介します。 この他にも、「Airbnbの事例に学ぶKubernetesとマイクロサービスのあり方 @ KubeCon Seattle 2018」という記事も執筆しているので、合わせてご覧ください。 また、このセッションのスピーカーであるMelanie Cebulaは、CloudNative Days Tokyo 2019のキーノートスピーカーとしても来日し、登壇しています。 後編書きました! セッションの背景 セッションスピーカーであるMelanieとBruceは、Airbn

    Kubernetesをぶち壊す10の奇妙な方法 (前編) - Qiita
  • CとRustで一から作るマイクロカーネルOS

    マイクロカーネルは浪漫に溢れる非常に作りがいのあるソフトウェアです。この記事は,「マイクロカーネルベースのOSの一から作ってIaaSで動かす」ことを目標に作ったマイクロカーネルベースのOS Resea(りーせあ)の設計と実装について軽くまとめた物です。 ソースコードはGitHubにあります。 マイクロカーネルとは Linuxのようなモノリシックカーネルでは色んな機能がカーネル空間で動きますが,マイクロカーネルではユーザプロセスたちが互いに通信しながらOSを作り上げます。プロセス・スレッド・仮想メモリ管理,プロセス間通信,タイマーといった必要最低限の機能だけをカーネルが担います。デバイスドライバやファイルシステムといった残りの機能は,独立したユーザプロセスとして動きます。たとえデバイスドライバが暴走しても他のコンポーネントを壊すことはないのです。マイクロカーネルは信頼性が高く,疎結合で美しい

    CとRustで一から作るマイクロカーネルOS
    nnhrsk
    nnhrsk 2019/12/15
  • スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services

    AWS Startup ブログ スタートアップのためのコンテナ入門 – Kubernetes 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。 なお Kubernetes 以前に、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 目次 Kub

    スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services