どうしてもドメインを永久保持できない企業向け 企業はどうドメインを捨てるべきか - web > SEO
コロナ禍中に取得された地方自治体のドメインがオークションで高値売買され、中古ドメインとして悪用されるなど、公的機関のドメイン放棄問題が注目されています。 11月25日のNHKニュース7でドメイン流用の件が報じられました。私も取材を受け少しご協力をしています。 www3.nhk.or.jp 公的機関のドメイン放棄問題の理想の解決は、今後は lg.jp、go.jp などの公的機関しか使えないドメインだけを使うようにすることです。 ただ今回の問題はコロナ禍初期の大混乱時、非常にスピーディにサイト立ち上げが求められていた時の話です。 信頼が求められる lg.jp などのドメインの利用には厳格なルールがあるのも当然です。あの混乱時期にルール改定も難しかったと思います。新規ドメインが選ばれた事は仕方がない事と思っています。 ただ、コロナ禍が落ち着いた今、無責任に放棄されるのは明らかな問題です。 今回の
Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
改正電気通信事業法が施行だけど、またしても何も知らなかったWebサイトやアプリ運用者のために書いておくぜ - フジイユウジ::ドットネット
2023年6月16日 から改正電気通信事業法が施行なんですけど知ってました？ これ、収益目的なら企業運営でも個人運営でもほとんどのWebサービス・スマホアプリが対象という、めちゃめちゃ広範囲にみんなが対応が必要なやつなんですけど、ヤバくない? 何もしてなくない? やっべえなというWEBサイト担当者/アプリ開発者が結構いそうな雰囲気がいんたーねっつから漂ってまいりました。 企業のオウンドメディアや、個人運営のアフィリエイト目的サイトなんかも対象になる場合があって、メディア系サイトはもちろんアプリ開発者にも影響ある感じですので、やるべき内容をブログにしたためておきます。 ※ぼくは法律の専門家ではないので、ちゃんと総務省の公式ドキュメントなどにも当たってくださいね。 ググると「外部送信規律」とか「電気通信事業者又は第三号事業を営む者」とか専門用語の記事ばっかり出てきて自分が何をしたらいいのかの情
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Cloud Operator Days Tokyo 2022 に動画登壇しました！
こんにちは。エンジニアリングチームの照井です。初めてインフラエンジニアwayに投稿します。 Cloud Operator Days Tokyo 2022 というイベントにおいて、「文書作成ソフトからの脱却 ～Markdownによるアラート対応手順書CI/CD～」という題名で「社内ドキュメント作成の自動化」について動画登壇させていただきました。このイベントではハートビーツがゴールドスポンサーとなっております。 なお、登壇動画はイベントページにて2022/06/27より公開されております。 Cloud Operator Days Tokyoのご紹介 Cloud Operator Days Tokyo は、クラウド運用者に焦点を当てた技術イベントです。 運用技術の発展やインフラ、アプリケーション運用に興味がある若手の教育、育成を目的に掲げています。 Cloud Operator Days Tok
複数ブランチ運用は『単一のコードベース』と言えるのか | CI/CD Conference 2021 by CloudNative Days
architect - システム設計 developer - システム開発 app-developer - アプリケーション開発 operator/sys-admin - 運用管理/システム管理 かの有名な The Twelve-Factor App は、その「コードベース」の章で「一つのコードベースと複数のデプロイ」が重要であると説いています。[1] 周りを見渡してみましょう。develop ブランチ release ブランチ main ブランチ... おやおや。複数のコードベースから複数のデプロイが生まれているではありませんか。 The Twelve-Factor App はもう古い、そんなのできていて当たり前などという言葉が聞こえてくることもある昨今ですが、そもそも当たり前すぎるセオリーすら満たせていない現場はあまりにも多そうです。 The Twelve-Factor App が間違
「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない コンテナのスペシャリストが語る、運用性を損なう8つの実装例
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it 原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOで
AWS から配信されるメールについて運用チーム視点でまとめてみた | DevelopersIO
本記事では、AWS 利用者（これから利用してみようと思われている方や利用開始直後の方も含む）全ての方を対象に、１年間 AWS から配信されるメールを確認し続けた（※）筆者が AWS から配信される各種メールにはどのようなタイプの通知があるの？といった疑問を運用チームの視点で解消すべく代表的なメールをピックアップし解説してみたいと思います。なお、AWS から配信されている全てのメールを網羅的に解説している記事ではないこと＆2021年6月時点での情報をベースに書かれた記事である点をご理解いただけますと幸いです。 （※）以下のブログにあるとおり、とあるプロジェクト対応中に AWS から配信されるメールを随時確認していた過去の経緯あり はじめに 筆者は、弊社の AWS 総合支援サービスであるメンバーズの中でサポートチームと位置付けられるオペレーションチームに所属しております。オペレーションチームは
魔窟と化した全文検索サーバーとふっかつのじゅもん - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズのクラウド黎明期から運用し続けていたSolrサーバーを Elasticsearchに置き換えるプロジェクトが先日完了しました。 プロジェクト完了報告もかねてプロジェクトのあらましを公開したいと思います。 はじめに このプロジェクトの主軸は『魔窟と化したレガシー技術をどう捌くか？』になります。 このプロジェクトの報告をする前に、いくつかエクスキューズをさせていただきます。 クラウド黎明期を支えてくれたSolrには畏敬の念に近い感謝をもっています レガシーな技術に対してマウントやディスリスペクトの意図はありません 魔窟にかかわることになってしまった人に対して負の感情は一切ありません 今回の採用している構成はElasticsearchのあるべきアーキテクチャではありません 今後、Neco 環境への移行を通して継続的に改善していきます サイボウズでのSolrの使い方と用語説明 サイボウズ
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
脆弱性対応（Heartbleed）の責任の所在 東京地判令元.12.20（平29ワ6203） - IT・システム判例メモ
クレジットカード情報漏えい事故に関し，その原因の一つと考えられる脆弱性対応が運用保守業務に含まれていたか否かが争われた事例。 事案の概要 Xは，Xの運営する通販サイト（本件サイト）を第三者に開発委託し，運用していたが，その後，2013年1月ころまでに，Yに対し，本件サイトの運用業務を月額20万円で委託した（本件契約）。本件サイトはEC-CUBEで作られていた。なお，XからYへの業務委託に関し，契約書は作成されておらず，注文書には「本件サイトの運用，保守管理」「ＥＣ－ＣＵＢＥカスタマイズ」としか記載されていない。 2014年4月には，OpenSSL*1の脆弱性があることが公表されたが*2，本件サイトでは，OpenSSLが用いられていた。 2015年5月ころ，Xは，決済代行会社から本件サイトからXの顧客情報（クレジットカード情報を含む）が漏えいしている懸念があるとの連絡を受け（本件情報漏えい）
極めてAmazon的な"メカニズム"というお話｜Yuki Nakazato｜note
今でこそクラウドやアレクサ、ビデオやミュージックといった多角的なビジネスを展開するアマゾンだが、もともとはオンラインの小売りであり、依然としてそれはビジネスの大きな部分を占めている。オンラインのコンシューマービジネスは、感謝祭時期のBlack FridayとCyber Mondayに照準を絞って（今はPrime Dayもあるが）、仕入れや配送センター及び実際の配送キャパシティの増強など、数か月前から準備に取り掛かり、その集大成としてこのPeak Periodを執行し、そして12月後半にはオフィスががらがらになる、というのが伝統芸である。9月後半か10月前半くらいになると、既に青色吐息の社員を見かけることも少なくない（そんな社員のためにお菓子やらが夕方になるとカートで運ばれてくる。残念ながら今年はなかったが）。 アマゾンの強さの一つの理由は、私はこうしたピークシーズンに向けた過酷なOpera
本日閣議決定された『デジタル・ガバメント実行計画』を”クラウドのレンズ”で読み解く | Amazon Web Services
Amazon Web Services ブログ 本日閣議決定された『デジタル・ガバメント実行計画』を”クラウドのレンズ”で読み解く 本日令和2年(2020年)12月25日、『デジタル・ガバメント実行計画』が閣議決定に至りました。 今回のブログでは、335ページの大部の政策集となった『デジタル・ガバメント実行計画』（以下、『実行計画』。全文はこちら）を、クラウドの観点から読み直すことで、特に政府部門・公共部門の各お客様にクラウド導入をご検討いただく判断の一助となることを目指します。昨年版から120ページ以上も大幅加筆された最新の『実行計画』では、何が謳われているのでしょうか？ 今回のデジガバ実行計画の”柱” 今回の『実行計画』には、（昨年までのバージョンでは見られなかった）４本のメイン・アイディアが新規に配置されています。トップページには、”社会全体のデジタル化を進めるために、まずは国・地方
後悔先に立たずなマルチクラスタ運用の知見がてんこ盛り「最高のKubernetes on AWSを実現するために」 #AWSSummit | DevelopersIO
「Kubernetes、考えることがいっぱいあって楽しいですね。今日はそんなKubernetesのお話です」 こんな謎の問いかけから始まった、Kubernetesセッション、皆さんご覧になりましたか？ Kubernetesで実現するアプリケーションの未来まで見据えたとき、最初に検討しないと一生後悔する忘れがちだけど考えないといけない知見がてんこ盛りのセッションでした。このブログでは、そのセッション内容を余すことなく解説。 EKS/Kubernetesの運用に自信がない Kubernetesクラスタの長期運用を真剣に考えたい クラスターのアップデートができず不安 そんなあなたの未来を明るく照らす知見が、このセッションには詰まっています。ぜひ、Kubernetesクラスタ運用に迷いがあるかたはこのブログご覧になって、未来の負債をこの場で削ぎ落としましょう。 もう、アレコレ悩まなくても良いの…!
Systemdとdocker-composeでカジュアルにdockerを運用する - Qiita
はじめに この記事はDocker Advent Calendar 2017の13日目の記事です。 コンテナ運用はk8sがデファクトにほぼなったような感じはしますが、オンプレのようなマネージドなk8sが無い環境で、コンテナ化を進めるにあたり、いきなりk8sクラスタを作るというのは敷居が高いです。 そこで、少しづつコンテナ化を始める繋ぎとしてdocker-composeとsystemdを使ってカジュアルにdocker運用してみたので、その際のTipsについて記載します。 ちなみにdocker-composeなので当然サーバ間をまたいだオーケストレーションの層は考えず、単に既存サーバのプロセスをコンテナ化して運用することで、まずはサービスの移植性を高めることを目的としています。 docker-composeだけで運用する際の問題点 サーバ単体で複数のコンテナを連携させるにはdocker-comp
【ネットワーク編】DeNAインフラノウハウの発信プロジェクト連載まとめ | BLOG - DeNA Engineering
2019年8月から2020年5月の10ヶ月間、[DeNAインフラノウハウの発信プロジェクト](https://engineer.dena.com/posts/2019.08/we_start_new_project_providing_itpf_knowhow/)としてIT 基盤部が蓄積してきた技術的ノウハウを発信してきました。IT 基盤部はDeNA全グループ・全システム基盤を横断して管理している部署です。 皆さま、 DeNAインフラノウハウの発信プロジェクトで発信した記事 はお読みいただけましたでしょうか？ 年末年始などを除いたほぼ毎週、記事を公開いたしました。長い連載であったため、記事を見逃してしまった方も多かったのではないかと思います。また、システム基盤を管理するエンジニアといっても、その領域は様々であり、「自分と関連のありそうな記事だけ読みたい」という方もいるかと思います。 そこで
自作サービスがDDoS攻撃された話 - 週休７日で働きたい
攻撃に立ち向かうイヌさんThe English version is available here. タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」「それはDDoSではない」という指摘に関して末尾に追記 (6/18)SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。 どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立
転職したらKubernetesだった件 - Qiita
TL;DR Kubernetes がどのように、人間の作業を自動化しているのかを、実際に Kubernetes がやっている作業を手作業で行なう ことで学びましょう。 このQiita の内容は、CloudNative Days Tokyo 2019 における発表の、「転職したらKubernetesだった件」を書き下ろし、実際にデモが行えるように修正を加えたものになります。 YouTube Speakerdeck この物語はフィクションであり、登場する団体名・会社名・人名等は架空のもので、実在する団体・会社・人物等とは、一切、関係がありません。 これまでのあらすじ ある日、某Z社に転職した稲津さんに与えられた仕事は、“Kubernetes の一員”になることだった！？ 某Z社は、親会社からの依頼で Kubernetes クラスタを運用しなければならなくなりましたが、 「Kubernetes
マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント
マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント：特集：マイクロサービス入門（終） マイクロサービスアーキテクチャへの移行を進める上で生まれた課題にどう取り組んだのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行後のテスト、CI/CD、運用監視を紹介します。 これまでの連載では、ECサイトであるOisixをマイクロサービスアーキテクチャへ移行させていくアプローチについて解説してきたが、今回は移行させた後の開発・運用について解説する。 併せて前回まで触れてこなかった開発時に留意しておいた方がいい継続的なメンテナンスや運用に関する内容についても解説する。 CI/CDパイプラインを生かした機動力のある開発 本連載の第5回でも「パイプラインファースト」という言葉について説明したが、開発当初からCI/CD（継続的インテグレーション／継続的デプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ECS×Fargateで実現する運用コストほぼ0なコンテナ運用の仕組み/ ecs fargate low cost operation
