クラウド大手のAmazon Web Services（AWS）を使うことは、業務の効率化やコストの大幅削減が可能になるとされている。一方で、AWSを使わないことで3年間で4億ドル（約527億円）以上の節約に成功した企業も存在したそうだ。アクセス解析システムを開発する「Ahrefs」がその成功例で、同社は日本を含む世界中に60万人のユーザーを抱えているため、膨大な量のトラフィックを処理する必要があるという（Ahrefs、GIGAZINE）。

同社が同一ハードウェアを5年間使い続けると仮定し、電気料金や通信料金を加味して「Ahrefsの1カ月当たりのサーバー1台当たりのコスト」を導き出した結果、サーバー本体のコストが月間1025ドル（約13万5000円）、電気代や通信料金が524ドル（約6万9000円）、合計1550ドル（約20万4000円）が必要となった。これをAWSで実現する場合の月額料金は、もろもろ合計で1万7557ドル（約231万5000円）が必要だという。

Ahrefsが所有するサーバー850台を30カ月間運用した際のコストは、3951万9025ドル（約52億1000万円）だった。同条件でAWSを利用した場合、4億4769万4623ドル（約590億3000万円）が必要という結果になったとしている。もしAWSを採用していたとしたら、Ahrefsの収益だけではAWS利用料を支払うことは不可能だったと話している。その上で持続的な成長に関心のある企業は、クラウドサービスの運用コストを再評価することを推奨すると述べている。

headless 曰く、

Apple Music でプレイリストが他人のものに置き換えられるなどの問題が発生しているようだ (9to5Mac の記事、 Mac Rumors の記事、 The Verge の記事)。

Reddit での報告によれば、自分が作ったものではないプレイリストが追加される、その一方で自分の作ったプレイリストが一部消える、最近半年ほどの間に追加したソングが消える、すべてのプレイリストが見たことのないものに置き換えられる、などの問題が発生しているという。問題は3週間以上前から報告されているが、現在も新たな報告が投稿されている。

現在のところ問題が報告されているのは iOS 版の Apple Music のみで、macOS 版での報告はないようだ。iCloud の同期をいったん無効化してから再び有効化すれば復旧する可能性もあるが、詳細は不明だ。

欧州の Amazon Web Services (AWS) では、データセンターのバックアップ用発電機を水素化植物油(HVO)燃料に移行開始したそうだ (Amazon のニュース記事、 Neowin の記事、 The Register の記事)。

再生可能で生分解性があり、毒性のないHVOは使用済みの食用油などから製造可能で、そのライフサイクル全体で石油由来のディーゼル燃料と比べて排出する温室効果ガスを 90 % 削減できるという。また、他のバイオディーゼルと比べて産業機械との互換性が高く、燃料システムの改造が必要ないほか、冬季の低温下でも安定した状態を保つ。これにより、AWS は既存のバックアップ発電機のタンクに HVO を注入してこれまで通り使用することができ、気候の異なるさまざまな地域で利用できるとのこと。

AWS ではアイルランドとスウェーデンのデータセンターを手始めに HVO への移行を進めており、将来的には欧州の全データセンターで HVO に移行する計画とのことだ。

ガートナージャパンが16日に発表したオンプレミスに関する展望によると、多くの日本企業がレガシーなオンプレミス環境の近代化を進める必要に迫られているという。また2026年までにオンプレミス・ベンダーのテクノロジの90%がクラウド・ネイティブの要素を取り入れた『(New)オンプレミス』になり、従来型 のオンプレミス・テクノロジは衰退するのではないかと評している（Gartner、オンプレミスに関する展望を発表、ZDNET Japan）。

2022年に富士通がメインフレームからの撤退を発表した影響もあり、レガシー・マイグレーションが再びユーザーの関心を集めている。IBM、NECを除くメインフレーム・ベンダーは、基本的に撤退の方向であるため、ユーザーは何らかのマイグレーション計画を立案する必要に迫られているという。一方でユーザーの60％に関しては、メインフレームからのマイグレーションで膨大な費用が必要だと見込まれることから、2026年までに移行を見送ると同社は予想している。しかし、メインフレームに関してもユーザー数が減少すれば、それによりベンダーから保守料金を大幅に値上げされる可能性もある。レポートでは、当にメインフレームでなければならないのか、使っているシステムは本当に必要かどうか議論が必要になるとしている。

headless 曰く、

クラウドストレージサービスの Backblaze が 2022 年版 Drive Stats SSD Edition を公開している (Backblaze のブログ記事、 Ars Technica の記事)。

Backblaze では 2018 年第 4 四半期からストレージサーバーのブートドライブとして SSD を使い始めており、以降は新しいストレージサーバー導入時と HDD 故障時に SSD をインストールしているという。2022 年 12 月 31 日時点で使用していた SSD は 13 モデル計 2,906 台。ストレージサーバーには顧客のデータを保存しないため、低価格な製品で十分なことからコンシューマーグレードの SSD を選択しているそうだ。ただし、ストレージサーバーにバンドルされている場合には、後述する Dell の SSD のようにエンタープライズクラスの SSD や M.2 SSD をそのまま使っているとのこと。

2021 年に 627,843 日だった全 SSD の年間延べ利用日数 (Drive Days) は 2022 年に 934,441 日まで増加し、これに伴って年間故障率 (AFR) は 2021 年の 1.05% から 0.98% まで減少している。特に 2021 年は年間の利用日数が 1,689 日と短かった Crucial の 1 モデル (CT250MX500SSD1) が 43.22% という高い AFR を示していたが、2022 年には利用日数が 105,365 日まで増加したのに伴い、予想通り 1.04% まで減少した。

全 SSD のライフタイム故障率を年単位に変換したライフタイム AFR は 0.89%。Dell の 1 モデルと Seagate の 4 モデル、WDC の 1 モデルが 0.00% となっているが、Dell と Seagate の 1 モデル以外は使用日数が短いため信頼区間 (CI) の幅は数十% 以上、最も幅の広い WDC の 1 モデル (WD Blue SA510 2.5) の CI は 0.00-1,320.00% となる。Dell の SSD (DELLBOSS VD) は M.2 SSD が PCIe カードにマウントされたサーバー専用製品で、ライフタイム AFR の CI は 0.00-0.60% となっている。このほか、CI の幅が 1.0% 未満の SSD は Seagate の ZA250CM10003 (ライフタイムAFR 0.66%、CI 0.30-1.10%) と ZA250CM10002 (ライフタイム AFR 0.96%、CI 0.40-1.30%) の 2 モデルで、いずれもコンシューマーグレードの製品だ。

headless 曰く、

2023 SpyCloud Identity Exposure Report によると、SpyCloud の研究者は 2022 年に流出した認証情報 7 億 2,150 万件を発見したそうだ (ニュースリリース、 Neowin の記事)。

2020 年にマルウェアに感染したデバイスは 2,200 万台が見つかっており、SpyCloud が確認した認証情報 7 億 2,150 万件の半数はボットネットから来たものだという。また、220 億台近いデバイスでは多要素認証のバイパスに利用可能なセッションクッキーが取得可能な状態にあり、14 億人分のフルネームや 3 億 3,200 万件の社会保障番号、6,700 万件のクレジットカード番号などを含む 86 億件の個人を特定可能な情報 (PII) が入手可能だったとのこと。

パスワードの安全性は相変わらず向上しておらず、2022 年にパスワードが流出したユーザーの 72 % が過去に流出したパスワードを再利用しており、話題の人物や出来事、製品等に関連するパスワードの人気も高い。SpyCloudが復元したパスワードのうち 327,000 件以上が歌手テイラー・スウィフトやバッド・バニーに関連する語句を含み、Netflix や Hulu に関連する語句を含むパスワードは 261,000 件以上、英国のエリザベス女王逝去や王室に関連する語句を含むパスワードも 167,000 件以上に上る。

政府関連組織では、昨年 2 件以上のパスワードが流出したユーザーのパスワード再利用率が 61 % に上り、最も多いパスワードは「123456」「12345678」「password」だったそうだ。政府関連組織は企業と比べてマルウェア感染デバイスによるリスクが高く、全世界の政府関連組織から 2022 年に流出した認証情報の 74 % 近くはマルウェアが送り出したものだったとのことだ。

Googleは14日、企業向けのクラウドサービスのGoogle WorkspaceやGoogle Cloudに、文章や画像を自動でつくる「ジェネレーティブ AI」を使った新機能を導入すると発表した。「Gmail」や「Google ドキュメント」では、書きたいトピックを入力するだけでAIに文章を下書きさせたり、過去のやりとりを要約させたりできるようになるという（GoogleCloud、Impress Watch、日経新聞）。

上司が会議の後で部下に要点を伝えたい場合、Gmailの画面に各参加者への簡単な指示を箇条書きにするだけでAIが文章を整えたりしてくれるという事例が上げられている。Google ドキュメントでも職種の募集要項作成を支援するなどができるようになるとされている。これらの機能は、今後数週間で一部のテストユーザーに提供される予定とのこと。

【追記】 米財務省と連邦準備理事会（FRB）、連邦預金保険公社（FDIC）は12日、SVBの顧客は13日から預金にアクセスが可能になると発表した。「13日から預金全額にアクセスできる」とした上で破綻により「いかなる損失も納税者が負担することはない」と表明した。報道によればイエレン米財務長官は預金者を完全に保護する方法で破綻処理を完了する措置を承認したとしている（日経新聞、ロイター）。その少し前に管財人であるFDICがSVBの売却に向けた競争入札を開始したとも報じられている。預金保険対象外の預金支払いにSVBの売却資金をあてることが目的だという（日経新聞）。

米SVBファイナンシャル・グループ傘下のシリコンバレー銀行（SVB）が10日に経営破綻した。同行の資産規模は全米16位で、2022年末の総資産は2090億ドル（約28兆円）だった。これは日本の大手地銀グループに匹敵する破綻規模のようだ。米連邦預金保険公社（FDIC）が管財人となり預金を保護する。破綻の要因としては、米連邦準備制度理事会（FRB）の急速な利上げによって取引先の新興企業の資金繰りが悪化した。その結果、預金引き出しが加速し預金額が減少したことにあるという（NHK、読売新聞、日経新聞）。

加盟銀行が破綻した場合、1人当たり原則25万ドル（約3400万円）までの預金が保護されるとのことだが、22年末の預金残高約1750億ドルのうち89%に当たる約1560億ドル（約21兆円）は預金保護の対象外。同行はシリコンバレーなどのスタートアップ（新興企業）を主な貸出先となっており、多くの企業の資金繰りに影響するとみられている。

またこうしたSVBに資金を依存していたベンチャー企業の中にはクラウドサービスを展開している企業もあり、一部にはクラウドサービスが停止する可能性も出ていたようだ（なるがみさんのツイート）。

「サインイン」「ログイン」「ログオン」「ログオフ」という言葉は、日本人だとなんとなく同じような感覚で扱われることがほとんどだが、海外サービスでは使い分けされていることもあるらしい。タレコミにあるように、このことがTwitterで話題になっていたようだ。この用語の違いは昔から指摘されているようで、ネット上ではいくつもの記事が上がっているが、CloudSEや社会人のためのビジネス情報マガジン、例文買取センターの記事などがコンパクトにまとまっている。CloudSEによると「ログオン」「ログオフ」はマイクロソフトの独自戦略として使われ始めたらしい。なお、日本企業のサービスでも英語版を作る場合は使い方に注意がいるといった指摘も見られる（CloudSE、社会人のためのビジネス情報マガジン、例文買取センター）。

あるAnonymous Coward 曰く、

「ログイン」は昔の船乗りの用語だ一般人向けには「サインイン」を使えとする文献が紹介されて話題に、はあんまりなってないですね

今回のことの発端は『ログインは「アカウント識別を受けること」サインアップは「アカウントを新規に作ること」』というTweet。ここからログイン/ログオン/サインインの違いについて、オライリーの書籍でログインではなくサインインが望ましいと言っているものがあることが「(ログインを使うことを)かなりボロクソに書かれていましたw」と紹介される。この書籍とは「インタフェースデザインのお約束 —— 優れたUXを実現するための101のルール」というものだそうでこのなかの「英語ページではlog inではなくsign inを使え」の項目で曰く、
・log in は18世紀の船乗りが航海日誌に記入することから派生した言葉だ。ソフトウェアのユーザは18世紀の船乗りじゃない
・sign in なら「受付で氏名を書く」という現代の現実に沿っていてわかりやすい
・単語化した login (logon) にいたっては言語としてありえない
・なお日本語版訳者は日本語のサイトではログインも多いしそのままでもとしてちょっと日和っている感じだが、サインインに馴染みがないというのもいまさらどうかと。あと紹介者はたぶんここからログインを使うのは日本だけと言っているようだが引用部分だけではそうは読めない
・(日本語版の)初版はタイトル部の「sign」を「sing」と誤記♪
・オライリーさんのEbook Storeは「Sign In」のページから「ログイン」
といった主張がなされている

これに対して「情報工学的には意味と歴史のある単語。情報システムが一般人に普及して消されようとしてる。」とお嘆きの方が登場。こちらは、
・コンピューターにユーザ情報を与える行為としての「log in」はおよそ60年使われている。log inと言われて丸太を連想する人なんてそうはいない
・「航海日誌を書く」という行為は今でも「logging」。「logは木の端に申し送り事項を書いてたことから来ていて、紙の航海日誌を書くのにlogを使うのはおかしい。今でも木を使うならいいけど」と言っているのと同じ。
・sign in でも「手書きの署名で利用開始するシステム」なんて(ほとんど)ないのでおかしいとも言えてしまうが言わないだろう
・login と一語にすることについても明確に触れていないがその記述を使っていることから問題とはしていない様子
とlog in否定側の問題点を指摘している

さて皆様はどうお考えでしょう。ログイン/ログオン/サインインの使い分けかたを定められていたり、表記変更を要求されたりといった経験ありますか?

おまけ
・ちなみにlog onはonlineでのlog inからだそうだ。へー。なおWindowsはunixではありませんのでくらいでlogonらしい
・あとこんなのあんまり紹介もしたくないが、どこの世界に「loginはパスワードありlogonはパスワードなし」なんてこと言ってる人がいるんですかね???

情報元へのリンク

米バイデン-ハリス政権は 2 日、すべての米国人が安全なデジタルエコシステムのすべての利点を確実に享受できるようにする国家サイバーセキュリティ戦略を発表した (ファクトシート、 The Verge の記事、 Ars Technica の記事、 戦略全文: PDF)。

現在のサイバーセキュリティ防御では個人や中小企業、地方自治体などの負担が大きい。どのように優れたセキュリティソフトウェアでもすべての脆弱性を防ぐことはできないことを認識したうえで、ソフトウェア開発時に適切な注意を怠った者に責任を負わせる必要があるという。ソフトウェアを開発する企業には革新を行う自由が必要なのと同時に、消費者や企業、重要なインフラ提供者への注意義務を果たせなければその責任を負う必要もある。

その責任はエンドユーザーや、商用製品に組み込まれたオープンソースコンポーネントの開発者ではなく、被害を減らすための対策を実施する能力の最も高い利害関係者に移動する必要があるとのこと。これにより、イノベーションとスタートアップ企業や中小企業が市場のリーダーと競うことのできる能力を維持しつつ、市場がより安全なソフトウェアを作り出すようになるとのことだ。

以前、文化祭で各展示の滞在人数を把握し記録するシステムの構築に関する話題を取り上げたが、そのときおこなわれたイベントとシステムの全体像に関してITmediaが記事にして取り上げている。イベントが実施されたのは、奈良県北葛城郡にある西大和学園で、2022年5月に学園祭の開催に当たり、クラウドサービス（AWS）を活用した映像配信システムや、チケット管理システムを開発したり活用したりしていたという（ITmedia）。

システム開発は外部の業者や学内のIT部門が作ったのではなく、生徒自らがクラウドで開発・提供を実施した点が特徴。担当をおこなったのは同学の「西大和学園技術統括局」（旧・生徒会電算部）。同局が担当したのは大きく分けて「公式サイト」「入退場管理システム」「チケット管理システム」「3DCGバーチャル校舎」「映像配信プラットフォーム「NYGstreaming」だったとしている。

多くのクラウドストレージサービスは、一定容量を超えて使うと有料になってしまうことが多いが、その対策としてYouTubeをデータストレージとして活用する方法が考案されたらしい。YouTubeには、1本の動画は｢256GBまたは12時間のいずれか小さい方｣という制約がある。しかし、本数に関しては無制限となっていることから、これに目を付けて容量無制限のストレージとして活用しているようだ（Hackaday、データを動画にしてアップロードしたもの[動画]、GIZMODO）。

元データの変換にはDvorakDwarf氏が開発した「ISG（Infinite-Storage-Glitch）」を用いているという。このツールは、バイナリファイルをビデオファイルにエンコードする役割を持つ。YouTubeの圧縮アルゴリズムの影響を回避するための対策もされているという。サンプル動画の見た目は昔ながらの砂嵐だが、きちんとデータが仕込まれているとのこと。動画は元のファイルの約4倍のサイズになるという。こうした行為がYouTube側の規約に反しているかは不明であるようだ。

headless 曰く、

Google は 1 万人以上をレイオフする一方で、主要 5 都市のオフィスでは Google Cloud のスタッフにデスクを交替で使用するよう指示しているそうだ (CNBC の記事、 Neowin の記事、 Ars Technica の記事、 The Register の記事)。

CNBC が閲覧した内部メモによれば、対象となるのはカークランド (ワシントン州) とニューヨーク市、サンフランシスコ、シアトル、サニーベール (カリフォルニア州) のオフィスで、同じ机を割り当てられたスタッフは同時に机を必要としないよう 1 日交替で出勤するよう求めているという。割り当てでない日に出勤した場合はドロップイン用のスペースを使うことになる。

新しい座席の配置は CLOE (Cloud Office Evolution) と呼ばれ、パンデミック前のコラボレーションにフレキシビリティを組み合わせたハイブリッドワークにより、不動産の利用効率を高めることが狙いだという。これにより、いくつかの建物は空くことになる。CLOE は現在パイロットプログラムとして仮に実施されているが、最終的にはさらなるスペースの有効利用を可能にするとのことだ。

2月14日頃から欧州全域でTeslaの提供しているアプリに「503サーバーメンテナンス」というエラーメッセージが表示されるトラブルがあったという。これは、サーバーにアクセスできずサービスが利用不可能になるエラーステータスだそうだ。この影響により、家庭用蓄電池のPowerwallへの接続や、公共の充電施設で自動車の充電が行えないなどの障害が発生しているという。Teslascopeへのレスを見るとスゥエーデンで17日の時点でも解消されていないとの報告もあるが、実際のところは不明（Metro News、Teslascope Twitter、Hacker Newsの関連スレッド、GIGAZINE）。

アプリの障害が発生していてもテスラ車を自宅での充電する分には問題がないという。しかし、テスラのスーパーチャージャーで充電ができないといった制約があるようだ。理由としてはスーパーチャージャーの使用料金の取引を行うための通信が行えないためだとしている。

あるAnonymous Coward 曰く、

後年サーバーサービス打ち切りになったら、テスラ車は「自宅での充電」しか出来なくなり、家庭用蓄電池のPowerwallは只の置物と化すのか。
2021年末には「テスラ車がサーバーエラーで開錠不可能に、締め出しを食らう人が続出」もあったとか。
凄げぇな、テスラの可用性（一応BEV一般にこの問題は及ばないと思いたいが）。
こういう話はネットワーク接続機器（それこそ住宅のドアの鍵とかでも）では、古来繰り返されてきた話。

クラウドストレージサービスのDropboxは、「Dropbox for macOS」において、外付けドライブのサポートが打ち切られたと発表した。同社によるとmacOSのAPIの仕様変更により、macOSにおけるDropboxのデフォルトのフォルダである「~/Library/CloudStorage」を別のフォルダに変更できなくなったためだとしている。これにより、外付けドライブへが使えなくなったとしている。APIそのものの変更であることから、回避方法は存在しないとのこと。Dropboxに保存・同期しているプロジェクトをローカルの外部ストレージとひも付けているユーザーなどに影響が出ているようだ（Dropbox、INTERNET Watch、GetNavi web）。