すごいちっちゃいことで。
Adobe全般と言うか、ビデオ、写真編集はファイル保存も含めてクラウドはあまり好きではないってかか、ブラウザベースが嫌い。
写真なら現像からファイル保存まで含めてです。
現像は、クライアント・ネイティブが反応が良くて、rawからの現像、補正が速くて、ファイル保存もとりあえずはローカルにします。
Adobeだと写真のファイル保存はAdobeのクラウドへ保存ができるんですが、とにかく使いづらい。
自分でフォルダ分けとかしないと結局、面倒。
ただ、写真に関しては最終的には私はOneDriveですがクラウドに放り込みます。
あとですね、これはクラウドと言うよりネイティブ・アプリがいいになるんですが、Teams、ZOOM、Slack、ChatWork。
Teams、ZOOMはブラウザでやるとウィンドウのサイズの調整が面倒だしカメラ・オーディオ制御がわからん。
Slack、ChatWorkはネイティブ・アプリの方が文字入力がレスポンスがいいし、通知もいい。
一応、企業システムとかも知っているらしいのですが、最近はサーバを自社所有でもDCに置くことがほとんどであまりパブリック・クラウドだからって意識はそこまでないんですよ。
と言うか、私はまぁ、都合コーダーとしておきますが、そういう開発者に、そこまでインフラ・レイヤーがクラウドだからオンプレだからって意識しないと言うかさせない。
コンテナとかに
… (もっと読む)
公共系のシステムと金融系のシステム。
どこの誰が管理してるか分からないのに、よくも信頼して個人情報満載の情報を預けられるなと。
他所の故障や不始末が原因のシステム停止を許容できない業務は全部自前でやってほしいなぁとおもいます。
拠点間通信とか。
守秘義務契約書です。それと、死亡した際のデータの扱いについての指示です。
マネーフォワードのような自分の資金を管理するアプリ、ウェブサービスが大好きでずっと使ってるかつ、同じように当時危機感を持っていた技術者です。（当時はまだひよっこの高専生でしたが..）
ひとつ理由として、公式なAPIに変更されたという点があると思います。
マネーフォワードのログイン方法は、対象となる金融機関などのサイトにマネーフォワード経由でログインIDとパスワードを入力しログインするという方法が取られていました。
つまり、仮想のパソコンのようなものを用意してそのパソコン上でログインをさせ、表示された残高などをデータとして持ってきて表示していたわけです。この方法をスクリーン・スクレイピングといいます。
この方法、ログインIDとパスワードが”絶対に”漏れなければ問題はありませんが、一般的なログイン方法からするとリスクが高い方法です。
一般的なログイン方法とは、ログインする際にログインIDとパスワードを入力するとそのパスワードを元にしたアクセストークン（期間限定のパスワードのようなもの）が付与され、次回以降はこのアクセストークンを用いてログインすることでパスワードを保存することなくパスワードを入力する手間を省くという方法です。
アプリなどで再度ログインを求められる際はこのアクセストークンが失効したことが原因であることが多いです。このアクセストークンの利点として期間限定であるが故、誰かに漏れたとしても
… (もっと読む)
技術的には少なくとも4つあります。まず主な3つ。
- マネージドサービス
- インフラのコード化(Infrastructure as Code)
- 課金体系
まずはマネージドサービスです。データベースのフェイルオーバーを自前で組むと面倒ですが、Amazon RDSだと簡単にできます。これは分かりやすいですね。
次にインフラのコード化(Infrastructure as Code)。AWSならCloudFormation、サードパーティならTerraformとかです。これはいくつもメリットがあります。使い回しができます。レビューもできます。間違いが少なくなります。
3つ目が課金体系。時間単位でも荒い方で、分単位、秒単位、あるいはサービスによってはミリ秒単位での課金です。例えばサーバレスプラットフォームのAWS Lambdaは128MBで1ミリ秒あたり0.0000000021USDです。
これを使って、ダイソーは83〜90%のコスト削減をしています。構築のコストは上がりますが、数年で元が取れるそうです。
例えばストレージのS3はいくつかの料金体系があります。使用頻度が低いものはGlacierだと1/5、Glacier Deep Archiveだと1/12の価格です。
真面目に最適化を考えると大変ですが、最近は自動化してくれますし、ちゃんと学習した人が少しの手間をかけるだけで結構安くなります。
なぜこれができるのかと言うと、推測ですがおそらくAWS内部では様々なデバイスを組み合わせているからです。
ストレージの場合、使用頻度が高いところはSSDやもっと高速なストレージ、使用頻度が低いところはより安いHDD、さらに使用頻度が低いところはさらに安いLTOテープを使い、ユーザにはデバイスを意識させず、あくまで使用用途で選んでもらいます。
ここまで3つ挙げましたが、もう一つ、とても重要な技術革新があります。それはVPC(Virtual Private Cloud)です。次の3つの利点があります。
- セキュリティ設定がOSでなくネットワークの責務にできる
- 設定をコードとして書ける
- 高度な知識が不要
クラウドを導入する際の障害となりがちなのがセキュリティです。例えば従来のVPSではセキュリティはOS側の責務でした。firewalldとかの設定で、OSごとにバラバラです。これがVPCなら簡単にできます。あくまで論理的な分け方ですが、個人レベルで専用ネットワークを持つことができます。しかも無料です。
2つ目は設定のコード化ですが、これは先に書いたのと同じです。
3つ目は、ネットワークの高度な知識が不要になります。正確には不要ではないですが、求められる知識が「Ciscoのルータの使い方」とかから「基本情報技術者の知識に毛が生えたもの」くらいに下がります。自分のようなバックエンドエンジニアが片手間で学べるくらいです。
ここまで色々書いてみましたが、自分はせいぜいLambdaを個人的に使ったくらいです。S3 Glacierとか使ったことありません。
ただ知っているのと知らないのは大違いです。知らない人はS3標準の価格だけ見て「オンプレより高い」と言います。RDSを使わずにEC2でデータベースを構築して「オンプレより高い」と言います(EC2でないといけないケースも稀にありますが)。
そういうのを「オンプレ脳」と言います。
「EC2が前提」を避けるためにはまず、さまざまなサービスを知る必要があります。深くなくてもいいですが、「ちゃんと学習した人」である必要はあります。
例えば自分が持っているのはAWS Certified Solutions Architect - Associate(AWS SAA)ですが、基本的に座学でできます。ただ範囲は広いです。現行のC02だと63個、C03だと131個のサービスについて概要だけでも把握しておく必要があります(参考記事)。
とは言え、まあ誰でも最初はしょうがないと思います。いきなり高度なサービスを使うのは大変なので。自分も最初はEC2から試しました。
ここまで4つ書きましたが、実はこの4つの前に一つ重要なことがあります。それは「0. セルフサービス」です。クラウドを名乗りつつ詳細は「お問い合わせ」という自称クラウドサービスが多すぎます。そんなのがクラウドを名乗っている現状があります。
政府情報システムにおけるクラウドサービスの利用に係る基本方針でも「正しいクラウドサービスのみを選択」として次のように書かれています。
従来型の共同データセンタの単なる延長線上にあるものや、単に仮想化技術を採用しただけのものは、本方針におけるクラウドサービスの定義には該当しない。
クラウドサービスとは、前述「クラウドサービスの利用メリット」で記述した「効率性の向上」、「セキュリティ水準の向上」、「技術革新対応の向上」、「柔軟性の向上」、「可用性の向上」に寄与するものであるとするものである。
クラウドと名乗っているが偽物だった、典型的な例がこれです。「貸与期間が終了したとして全データが削除されたという」と書いていますが、まともなクラウドではそもそも貸与期間という概念がありません。電気、水、ガスを契約する際に更新手続きをしないと止まる、そんなことはあり得ません。必要なのは最初の契約と支払いだけです(ガスは立ち合いが必要ですが)。
このような電気、水、ガスのように使った分だけ請求する考え方をユーティリティコンピューティングと言います。この考え方自体は60年前からあったようですが、これを実現したのがクラウドです。
0 コメント:
コメントを投稿