  |
はてなキーワード: さくらのクラウドとは
https://b.hatena.ne.jp/entry/s/blog.tomoya.dev/posts/the-easiest-web3-textbook-is-really-bad/
や、それ以外もそうなんだけど、著者は非常に抽象度の高いマクロな視点からざっくり語っているので、ミクロな面では実態と異なるのは当然なんだよ。
著者が「地球は丸い」とざっくり言ってるだけなのに、
やれ富士山があるから丸くない、日本海溝があるから海の水全部抜けば丸くない。みたいな頓珍漢な批判が横行している・・・。
地球が丸かったら、下側の人は落ちちゃうじゃんｗプークスクスしてる人すら居る。
そりゃすべての規格はオープンなんだし、自宅に2台のPC同士でLAN組んで通信させることもできるし、
なんなら自宅のサーバをインタネット上に公開することだってできるんだから、ミクロな面では独占されてないでしょうよ。
だけど、何か実用的なサービスをやろうと思ったら、結局、グーグル・アマゾン・マイクロソフトのクラウド借りる羽目になるじゃん？
3社に独占されてるじゃん！
そこに、さくらのクラウドやGMOクラウドや、その他の泡沫クラウドを加えたところで、世界規模でみてもせいぜい数百社くらいにかならないでしょ。
Web3 になると、ネット接続されたすべての端末が事実上のサーバサービスの提供者となるので、
究極的な未来では誰も大手クラウドサービスを借りる必要が無くなる。
自分の端末がオフラインの時でも、その時オンラインになっている端末が肩代わりしてサービスを提供し続けるし、
逆に自分の端末がオンラインになれば、他のオフラインの端末の肩代わりをちょっとだけ負担する。
今はまだ過渡期だから、大手クラウドと縁を切れる状況では全くないけれど、IPv4が使われなくなるころには、
そういう世界に代わってるはず。
別増田さんも書いてくれている ( anond:20220722005048 )けど、
究極的な未来では、ネット接続されたすべての端末が協働して一つの仮想的なハードウェア基盤を作り上げるので、
今はまだスマートコントラクトという、それこそ原始的なアセンブラレベルのコードしか動かないけど、
IPv4が使われなくなるころには誰も意識することなく、ブロックチェーン上に構築されたOSを使うことになります。
携帯電話が無かった時代に、電話を持ち歩く話をしたら、電話線どうすんだよｗｗｗみたいにみんな思ったじゃないですか。
自動車電話が出来た時、あーはいはい。無線使うのね。移動中は通話が切れるから止まって話すの？だったら公衆電話使えよｗｗｗとか言ってたじゃないですか。
それが今では、誰もが電話を持ち歩き、その電話の上でＯＳが動き、いろんなアプリ使いこなしてますよね。
Web3の話しは、黒電話と世界最初のスパコンCDC 6600を並べて、
サーバに複数のディスクを追加してRAIDを構成することはできますか?
ソフトウェアRAIDを使用することで可能です。ただし、さくらのクラウドでは以下の理由により非推奨としています。
1サーバに接続可能な最大ディスク数は3台のため、構築可能なRAID構成パターンが限られる
ストレージ内データのバックアップはストレージサーバごとに異なり、バックアップデータからの復旧時に各追加ディスクのバックアップ取得時間が異なってしまうためリストアができなくなる場合がある
https://manual.sakura.ad.jp/cloud/support/technical/storage.html
Playbooks — Ansible Documentation
railsbox - Fast and easy Ruby on Rails virtual boxes
Ansible入門 (全15回) - プログラミングならドットインストール
Amazon.co.jp： 入門Ansible eBook: 若山史郎: Kindleストア
Amazon.co.jp: Ansible Configuration Management 電子書籍: Daniel Hall: Kindleストア
Red HatがITオートメーションのAnsibleを$150Mで買収へ…OpenStackデプロイをDevOpsのために簡易化
Git Clone (スタートアップスクリプトID:112600117316)
指定のGitリポジトリをcloneし、指定の実行ファイルを自動的に実行します。
https://github.com/philc/terraform
fog - The Ruby cloud services library
A list of base boxes for Vagrant - Vagrantbox.es
Discover Vagrant Boxes | Atlas by HashiCorp
https://github.com/ryotarai/itamae
Itamae - Infra as Code 現状確認会 // Speaker Deck
Amazon.co.jp： Chef実践入門 ~コードによるインフラ構築の自動化 (WEB+DB PRESS plus): 吉羽 龍太郎, 安藤 祐介, 伊藤 直也, 菅井 祐太朗, 並河 祐貴: 本
Docker - Build, Ship, and Run Any App, Anywhere
[翻訳] Dockerについてよくある勘違い | TechRacho
Puppet Labs: IT Automation Software for System Administrators
これまで他の人に用意してもらったサーバで自分のプログラムを動かしたことはありましたが
自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。
作業を進める上で困ったり考えたりしたことを書いていきます。
ちなみにサーバ自体はさくらのクラウド、OSにはCentOSを使用しているので、それ前提のお話になります。
最初にサーバを起動してから速やかにSSHとファイヤーウォールの設定を変更しました。
はてブなんかでも定期的に話題になっているのでおなじみですね。
・SSHやHTTP(S)など、どうしても公開しなければならないポート以外は遮断する
さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています。
後から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので
別にOS再インストールしなくてもiptablesの設定を変更できたんですよね...
逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログインの環境が残ってしまうので
パスワードの管理には引き続きしっかり気を使う必要がある。ということでもあります。
httpd,php,mySQL,memcachedなど必要なサービスをインストール、設定し
作成したWebアプリのプログラムを乗せて動かしてみました。が、動作が重いような...
開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています。
abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。
開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2Gと
CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ
特に使っていないと思われたipv6を停止した途端にパフォーマンスが改善されました。
ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています。
デフォルトで有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。
パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。
spfの設定を行なう、メールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。
試しにHotMailとexciteのメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。
困り果てていたところ、エラーの内容からサーバのIPがspamhousにスパム送信元として登録されていることが判明しました。
postfixのホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailがスパム送信元として通報してしまったようです。
設定を修正し、spamhousに解除依頼を提出。事なきを得ました。
クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。
と、自分で勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。
実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし
そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。
速度の低下が気にかかったため、いくつかの候補を実際に動かし
phpのスクリプトから1万件のデータ読み書きを行うという形でmemcachedと比較してみたところ次のような結果に。
| サービス | 1万件書込 | 1万件読込 |
| memcached | 2.55秒 | 2.30秒 |
| handlersocket | 21.23秒 | 2.71秒 |
| InnoDB | 20.23秒 | 5.10秒 |
| kyotoTycoon | 8.22秒 | 7.72秒 |
さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかかからないという結果が意外でした。
しかしながら書き込みのほうではhandlersocketもmemcachedの10倍近くの時間がかかっており、少々速度的な影響が気になってきます。memcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。
結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています。
実行系と参照系に分ける形でmySQLのレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。
一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。
例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで
実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまいます。
レプリケーションするテーブルを限定する場合はプログラム側でも注意を払わないと危険です。当たり前ですが。
監視といえばcactiやnagiosが定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。
簡単な設定でloadaverageやメモリ、HDDの使用量をチェックできるほか
httpdやmysqldなどといったサービスのプロセスを監視し、もし落ちていたら自動で起動してくれるので助かります。
パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムはWebに晒しておきたくない。
というわけで、一部のWebアプリを秘匿する設定を行いました。
管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても
上記のようなコマンドで管理画面のWebアプリを置いたサーバへログインするだけです。
ブラウザのアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。
サーバにログインできる人でなければ実行できないことなので、気分的にある程度安心します。
自動でログのバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。
調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。
具体的には、authorized_keysに
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...
などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり
接続のフォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。
commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば
ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file
などとしてログインの結果をファイルに書き込むだけで、簡単にファイルの転送が実現できます。
他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。
たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。
今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。
現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています。
個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。
既存のサービスで近いのは「あわせて読みたい」や「zenback」、各社提供のRSS相互リンクサービスなどになるでしょうか。
広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています。
現時点ではサービス本体のプロモーションに苦心するという本末転倒そのものの状況でありますが、もしよろしければ見ていただけると嬉しいです。
