「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

【2017年版】 OS問題を考察する | from Opensouce.com / Gordon Haff

  いまだに、オペレーティングシステムなくては解決しない問題がある。

 2016年2月7日 | Gordon Haff (Red Hat)

 画像: Internet Archive Book Images. Opensource.com.による一部加工。 CC BY-SA 4.0

  オペレーティングシステムの歴史は、コンピューター黎明期から、今日まで続いてきた。コンピューターの歴史であると言っても過言ではないだろう。
 1950年代後半、大型汎用コンピュータの管理者が記述した、コンピューターの維持管理情報を簡単に示すためのプログラムが、最初のOSとされている。それから半世紀、IBMのOS/360、Bell LabsのUNIXなど、さまざまなオペレーティングシステムが世に登場し、活躍の場を広げてきた。

  オペレーティングシステムの発展は、システムに多様かつ実践的な機能を持たせることになった。それではOSはどのようにしてソフトウェアの発展に貢献してきたのかを、3つのカテゴリに分類して説明しよう。

 

  まず、オペレーティングシステムには、物理システムの情報を掌握する役割がある。そこから得られた情報をアプリケーション・ソフトウェアに反映して、ハードウェアとの齟齬を起こさないようにさせている。
 しかし、OSで得られた利点はそれだけではなく、ハードウェアの発展にもつながった。新たなプロセッサに対応したり、サーバーデザインに別の視点が産み出されたのは、オペレーティングシステムの役割があってこそだ。逆に、それらの面でアプリケーション開発者が寄与できた事例はない。
 これからのITの発展に、ハードウェアの進化が欠かせないことは言うまでもない。
 機械学習などのソフトウェアが次のトレンドを握るころには、今まで長いことITをけん引してきたとされるCMOSスケーリング技術でさえ、もはや必需とされなくなっていくことが予想される。
 ソフトウェアの機能を向上させるために、クラウドを適宜用いる技法は瞬く間に広がりを見せた。そこでますます重要になることは、抽象化レイヤをいかに移植可能にするかということだろう。

 

  次に、カーネルに的を絞れば、アプリケーションが要求してくる処理をこなしているのは、OSのほうだといえる。スケジューリング、電源管理、アクセス許可、メモリ割り当て、その他低レベルな処理業務や、システムを効率的に安全に保つための監視業務も行っている。

  そして、オペレーティングシステムは、「ユーザーランド」というインターフェイスを通じて自身のサービスを展開している。ロギング、パフォーマンス解析、ユーザーが作成したアプリケーションの実行には、これが欠かせない。
 オペレーティングシステムはAPI(application programming interface)を介して、アプリケーションの処理を矛盾なく行っていく。APIはオープン標準に基づいている。
 さらに、商用利用を想定しているOSにおいては、サードパーティーアプリケーションとして、ビジネスに役立つ技術を提供する。信頼できるコンテンツ・チャンネルをプラットフォームに追加できる仕様になっているものも多い。

  コンピューター処理ランドスケープにおいても、ここ2年ほどで大きな変化が見られた。基幹システムに常駐しながら、我々がどのようにOSを使おうとしているのか、何をしたいのかをOSに反映させる能力が上がった。それにより、処理基盤の質が急激に向上し、アプリケーションのパッケージ方法にも影響を与えた。ただし、急激だったがゆえに脆弱性の心配はある。

 

  コンテナ技術

  オペレーティングシステムのシングルコピーをコンテナと呼び、その中ではアプリケーションを動かせるようになっている。これにより物理サーバーで独立的にアプリケーションを運用できる。
 コンテナはオペレーティングシステムの完全コピーなため、仮想化OSを介してハードウェアと通信しあえる。簡単にいえば、仮想化OSはハードウェアを模したもので、コンテナはオペレーティングシステムを模したものである。実は、この点が仮想化OS上に仮想マシンを設置する手法と異なる部分だ。
 そして結果的に、コンテナが使うシステムリソースは仮想マシンよりも少なく、アプリケーションに対する負荷が多すぎてパフォーマンスが落ちることが少ない。 
 近年になってコンテナが脚光を浴び始めた理由に、システム負荷が低く動作環境を変えてもあまり問題がないことと、レイヤーを組み合わせることでアプリケーションを移植できる機能が新たに追加されたこととがが挙げられる。
 アプリケーションを移植しやすいという点で、コンテナをビジネスに使うという選択肢が現実味を帯びてきたが、それでも主流になったとはいいがたい。(アプリケーション仮想化を考えていただければわかりやすいだろう。)

  コンテナはLinuxカーネルのプロセスモデルを採っていて、名前空間(process, network, user)や、 cgroups、特権の確認などが使用できる。コンテナがシステムからある程度の独立性を有しているにもかかわらず、驚くほど充実した機能を扱える理由がここにある。
 よって、コンテナ化を理解するには、オペレーティングシステムの概念を学ばないかぎり難しい。


 また、ここ数年で起こった重要な出来事に、オープンソース、オープン標準の担う役割が拡大したことが挙げられる。
 たとえば、Linux財団の傘下で行われている、Open Containerの共同開発プロジェクトは、その中心課題を、「コンテナ・フォーマットとランタイムの標準規格制定」に据えている。
 

  コンテナや、ソフトウェア定義基盤(OpenStackなど)などの、マイクロサービスを提供する技術に合わせて、Linuxを設計しようという動きも始まっていることも特筆すべきだろう。
 ソフトウェアの歴史の陰に、OSの成長があることを忘れてはならない。OSを発展させないことには、ソフトウェアに数々の機能や、開発環境を与えられない場合がある。ネットワークのTCP/IPや、そのほかのセキュリティのことも考えた機能を作るためのサイクルなどがそれだ。
 
 

  スケールの問題

  もう一つ、この先大きな意味を持つ変化がある。スケールポイントに対するリソースの問題が、データセンターのように大きなサーバーで発生しやすくなったことだ。これはウェブ黎明期から「いつかは起こる」と予想されていた問題である。
 要は、サーバーの量ばかりには頼りきれなくなってきたのだ。近頃のサービス偏重スタイルに対応するためにも、情報を「送電」するようにサーバーを使用する方式や、顧客に渡すソフトウェアの構造を、見直す必要性が見えてきた。

  そこで注目されたのが、「マイクロサービス」である。これは、もともとクラウド用に開発されたわけではないものの、現在のクラウドの使用方法にもつながっている考え方だ。コンテナの中にあるアプリケーションは、この方式をもとに作成されているので、コンテナを扱っている者なら、切っても切り離せない関係にある。
 マイクロサービスは、Service Oriented Architecture (SOA)を思い起こさせる、とても実践的な手法だ。様々な要素を組み合わせてアプリケーションを作成するので、開発の道筋をはっきりと決めやすい。アプリケーションにどのような機能を載せたいかが具体的に決定すれば、それに応じて構造をきめ細かく調節することも簡単だ。それぞれの構成要素にはアドレスがつけられて、素早いアップデート、スケーラビリティ、フォールトトレランスを実現できる。
 ところが、従来のモノリシック・アプリケーションは予定外の変更が欲しくなっても、それがほとんど効かないという欠点があった。

  もちろんマイクロサービスを導入したところで、サーバーが増えるわけではない。ただ、部分変更が利きやすく、メンテナスが簡単になるということと、スケジューリングと必要な情報がすぐに抽出できることから、従来よりも管理の効率化を図ることができた。
 この方式を応用すれば、データセンター・リソースの質を向上し、コンピューターそのものをさらに活用できる可能性があった。これはOS開発の方向性ですら決定づける重要な発見だった。

  Linux財団の傘下にある Cloud Native Computing Foundation (CNCF)は、「いくつもの工程を自動管理、マルチテナントにすることで、分散システム環境をさらに進化させること」を目標に、Kubernetesの開発に参加している。(Kubernetes=もとはGoogleにより設計されたクラスタ管理システム。現在はRed Hatを含む多数の組織を開発貢献者に抱える。)

 

  セキュリティ

  セキュリティが堅いに越したことはない。そのためにパフォーマンスをチューニングしたり、信頼性を高めるべく検定や認証を受けることは、今や仮想の世界でも当たり前のことである。

  情報セキュリティの観点が、現在のソフトウェア設計の状況を一変させてしまったことは否めない。
 たとえば、顧客や取引相手がアクセスできるシステムやデータに制限をかけなくては、Software-as-a-Service (SaaS)アプリケーションに、ラップトップからもスマホからもアクセスしたり、有料クラウドサービスを健全に運営することもままならない。

  オープン開発モデルは、セキュリティの面でその実力を発揮する可能性が高い。一定の基準をもうけ、テストを繰り返すことが可能で、妥協さえなければ、とても産業に向いているスタイルだといえる。
 脆弱性が発見されれば、開発者やベンダーのコミュニティ同士で連携を図り、コードのアップデート、セキュリティ注意報の発信などの行動を打ち出せる。企業やその他組織と連絡を取り合えば、新鮮な情報が得られ、技術の発展にも貢献できる。

  オープンソースにしている限り、アプリの構成要素は他のソフトでも再利用可能だ。マイクロサービスを駆使して、アプリケーションを分解的に制作する必要性は、これから増していく一方だろう。
 このように、急激な進化を遂げるソフトウェアに対し、OSが進化しなくては使えない機能を持ち合わせているソフトウェアのことを考えると、OSの開発も同じようにぬかりなく行わなくてはならない。
  Linuxコンテナがその典型だが、オペレーティングシステムの実力をさらに引き出せば、他にも新たな戦力が生まれる可能性がある。

 現在のLinuxにはすでに、複数のオープンソース・セキュリティ・ツールボックスが存在する。(たとえば、強制アクセス制御を担うSElinux、幅広いユーザースペース、 kernel-hardening機能、ID管理、アクセス管理、暗号化など。)
 だがそれに加えて、コンテナを分離したり、ハードウェアにソフトウェアを対応させる能力や、ソフトウェアのタスクを担う機能など、ソフトウェア定義インフラの改良が求められている。

 

  変わっていくところと、変わらないところ

  オペレーティングシステム開発や、システム監視に求められる事項に変化があったことは確かだ。カスタマイズ、チューニング、シングルサーバーの最適化などよりも、スケールの自動デプロイに焦点が当てられることは、今日ならではの出来事だろう。そして同時に、セキュリティの重要性は増していく一方で、システムのリスクを広く周知したり、攻撃の被害を少しでも抑える対策が課題となっている。

  アプリケーションは、もっと柔軟で、携帯性に優れ、配布しやすく、丈夫で、軽量でなくてはならない。配置、サービス供給、セキュリティ、これらの自動化も求められる。
 中にはずっと動き続けなくてはならないプログラムがある。紐解けば、おかしくなった原因がわからないようでは困る。たとえ動作環境が変化しても、それに対応しなくてはならない場合がある。
 アプリケーションはOSなしには動かない。ソフトウェアに求められるものが、オペレーティングシステムにも求められている。
 

 

PDF
更新日:2017-07-08 16:27:02 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://opensource.com/16/12/yearbook-why-operating-system-matters Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

僕がHugo静的サイト・ジェネレータをGitLabで使うときにしたCI設定 | from Leow Kah Man - Tech Blog

 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポジトリにNodeJS Dockerイメージを構…2017-11-18 13:00:02

【GitLab 公式 を訳してみた】Dockerイメージを使う

GitLab Documentation > GitLab Continuous Integration (GitLab CI) > Docker integration >Dockerイメージを使う  GitLab CIは、GitLab ランナーと連携して、Dockerエンジンを様…2017-11-18 00:10:16

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン があることに気がつきました。  原…2017-11-17 23:50:27

【GitLab 公式 を訳してみた】GitLab CI/CDで使える変数

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CDで使えるAPI変数  GitLab ランナーは、CIから送られてきたjobをもとに、ビルド環境を整えます。…2017-11-17 23:50:02